Messages in this thread | | | Date | Wed, 06 Mar 2002 10:33:16 +0100 | From | Martin Dalecki <> | Subject | Re: bitkeeper / IDE cleanup |
| |
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.
- 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/
| |