From: Martin Dalecki <dalecki@evision-ventures.com>
To: Andries.Brouwer@cwi.nl
Cc: linux-kernel@vger.kernel.org
Subject: Re: bitkeeper / IDE cleanup
Date: Wed, 06 Mar 2002 13:52:30 +0100 [thread overview]
Message-ID: <3C86110E.7020703@evision-ventures.com> (raw)
In-Reply-To: <UTC200203061212.MAA182963.aeb@cwi.nl>
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.
next prev parent reply other threads:[~2002-03-06 12:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-06 12:12 bitkeeper / IDE cleanup Andries.Brouwer
2002-03-06 12:52 ` Martin Dalecki [this message]
2002-03-06 14:26 ` Alan Cox
2002-03-06 14:52 ` Alan Cox
2002-03-06 14:55 ` Martin Dalecki
-- strict thread matches above, loose matches on Subject: below --
2002-03-06 13:09 Andries.Brouwer
2002-03-05 23:58 Andries.Brouwer
2002-03-06 9:33 ` Martin Dalecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C86110E.7020703@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox