Jens Axboe wrote:

On Tue, Oct 26 2004, Jeff Garzik wrote:

quoted

So, we return the proper return code, and ioctls we don't handle
start to work again.  Overall, though, this is a fragile way to do
things in the block layer, IMHO.

Well, it's pretty much the universally accepted way of signalling this
information, I'm not sure I agree. The crappy part is that EINVAL is so
wide spread as well.

My point is that most Linux APIs don't apply default behavior by means 
of a magic return code.

Each block/scsi/etc. driver should provide their own ioctl handler as 
the highest-level callback.  Then, each individual driver decides its 
fallback strategy for unknown ioctls -- in most cases, by calling 
"libata_ioctl" or "scsi_ioctl" or "block_ioctl".

In this manner, ioctl handling cascades naturally up through the layers, 
without magic return codes.

The current "top-down" ioctl handling implementation leads to the 
current situation:  a bunch of ->ioctl() callsites scattered through the 
generic block ioctl handling code.

	Jeff