Skip to contentSkip to conversation

bitkeeper / IDE cleanup

DISCUSSION [email protected] 2 participants 2 messages Mar 5, 2002 – Mar 6, 2002

lore
Share & tools
lore
#0 lore raw
Quoted 1 line · Andrew Morton

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

#1 lore raw
Quoted 9 lines · [email protected] wrote:
Quoted 2 lines · Andrew Morton

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

Seconded.

Quoted 7 lines

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?

Quoted 4 lines

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.