bitkeeper / IDE cleanup
Quoted 2 lines
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.
Quoted 2 lines
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.
Andries
Quoted 7 lines · [email protected] wrote:
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 3 lines
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.
They are not misguided - they are done to enable users to filter SSSCA disk hooks and other extremely unpleasant things like CPRM
Quoted 2 lines
3. Why do we have something like genric cdrom ioctl handling layer, which is basically just adding the above hooks?
That bit is needed. You want unpriviledged processes to issue a subset of the available commands so users can do things like play music. Those ioctls for CDROM are also rather important for back compatibility.
Thats a seperate but important case.
There are two things I think you must consider
#1 "Make the simple things easy" - abstract common cd interface and
friends. Unpriviledged but with strict limits on what can be issued
#2 "Make the hard possible" - the direct "I know what I am doing"
CAP_SYS_RAWIO interface
#3 Ioctls that must be issued with kernel help because they change
interface status and must synchronize both the device and the controller (eg 'go to UDMA3')
What can hopefully go is ioctls that are complex, setuid required and could be done by #2.
Alan
Quoted 14 lines · Alan Cox
Quoted 2 lines
3. Why do we have something like genric cdrom ioctl handling layer, which is basically just adding the above hooks?
That bit is needed. You want unpriviledged processes to issue a subset of the available commands so users can do things like play music. Those ioctls for CDROM are also rather important for back compatibility.
Thats a seperate but important case.
There are two things I think you must consider
#1 "Make the simple things easy" - abstract common cd interface and
friends. Unpriviledged but with strict limits on what can be issued
Quoted 8 lines
#2 "Make the hard possible" - the direct "I know what I am doing"
CAP_SYS_RAWIOinterface#3 Ioctls that must be issued with kernel help because they change
interface status and must synchronize both the device and the controller (eg 'go to UDMA3')What can hopefully go is ioctls that are complex, setuid required and could be done by #2.
Amen. I was of course not arguing against the cdrom abstraction layer.