Re: bitkeeper / IDE cleanup

Re: bitkeeper / IDE cleanup

[Andries.Brouwer]

> 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.

Andries

Re: bitkeeper / IDE cleanup

[Martin Dalecki]

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.

Re: bitkeeper / IDE cleanup

[Alan Cox]

> 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

Re: bitkeeper / IDE cleanup

[Alan Cox]

> 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

Re: bitkeeper / IDE cleanup

[Martin Dalecki]

Alan Cox wrote:
>>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.

Amen. I was of course not arguing against the cdrom abstraction layer.

Re: bitkeeper / IDE cleanup

[Andries.Brouwer]

    From dalecki@evision-ventures.com Wed Mar  6 13:53:24 2002

    > 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:
    ...

    Actually Alan Cox convinced me that it still makes sense to have a
    IOCTL_ATA_DRIVE_TAKE_ME_HARD_FROM_THE_REAR, but ...

Aha, so you are convinced. That is what I hoped to achieve.

Andries

bitkeeper / IDE cleanup

[Andries.Brouwer]

Andrew Morton writes:

> fwiw, I prefer to not use bitkeeper, for the reasons which you outline.

Seconded.


Martin Dalecki writes:

: Disable configuration of the task file stuff.
: It is going to go away and will be replaced by a truly abstract interface

Comment #1: Please observe the difference between cleanup and development.
 I think your patches already went too far under the "cleanup" heading.

Comment #2: We need a nice, general interface for the usual things,
 and a very detailed direct-to-hardware interface for special purposes.
 [Change the behaviour of a zip drive from "big floppy" to "removable disk"
 and back. Take care of passwords on disks. Unstroke a 32+GB disk. Etc.]


Andries

Re: bitkeeper / IDE cleanup

[Martin Dalecki]

Andries.Brouwer@cwi.nl wrote:
> Andrew Morton writes:
> 
> 
>>fwiw, I prefer to not use bitkeeper, for the reasons which you outline.
>>
> 
> Seconded.
> 
> 
> Martin Dalecki writes:
> 
> : Disable configuration of the task file stuff.
> : It is going to go away and will be replaced by a truly abstract interface
> 
> Comment #1: Please observe the difference between cleanup and development.
>  I think your patches already went too far under the "cleanup" heading.

Plese note that the mail in wich I did send this particular patch didn't
contain the cleanup term. OK?

> Comment #2: We need a nice, general interface for the usual things,
>  and a very detailed direct-to-hardware interface for special purposes.
>  [Change the behaviour of a zip drive from "big floppy" to "removable disk"
>  and back. Take care of passwords on disks. Unstroke a 32+GB disk. Etc.]

Wen don't need "a nice general interface for the usual things". We need
the POSIX interface to them ;-).

However I agree that there is need for advanced features.
But first of all please notice that the
current "TASK FILE" code found there is not quite there. Second
please note that I would rather have a true lean *abstract* ioctl/sysctl
based interface to the really common things like spin down for example
and a tinny ioctl based interface for the people who love to break
hardware by software. Not quite what is there - the current taskfile
just tryes and fails (it's really hard to handle interrupts in user 
space) to map every single ATA-6 standard command to an ioctl().

The supposed validation of the commands prevents basically it's true
purpose as a back door for vendors loving to do things like controller
firmware updates through undefined commands.

I hope this makes my opinins clear.