Andries.Brouwer@cwi.nl wrote:
>>Plese note that the mail in wich I did send this particular patch
>>didn't contain the cleanup term.
>>
>
> You forgot to check the Subject line.
>
>
>>I would rather have a true lean *abstract* ioctl/sysctl
>>based interface
>>
>
> I very much distrust the possibility of defining any abstract interface.
> For special purpose things one just wants to send certain commands and
> data to the disk, and user space knows which commands and what data,
> and the kernel doesn't, so has to allow user space access.
Well then please answer the following:
1. Why do Windwos, FreeBSD, Darwin and Solrais provide generic hooks for
device probing, powerstate handing and so on?
2. Why do they get away with an interface half the complexity of the
linx IDE ioctl mess?
3. Why do we have something like genric cdrom ioctl handling layer,
which is basically just adding the above hooks?
Actually Alan Cox convinced me that it still makes sense to have a
IOCTL_ATA_DRIVE_TAKE_ME_HARD_FROM_THE_REAR, but I still don't see any
argument in favour of the current half-finished code behind
HDIO_DRIVE_TASKFILE, which even by concept doesn't provide a true
backdoor for "vendor specific" mess, due to the misguided attempts
for command format parsing found there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:54 EST