From: Martin Dalecki <dalecki@evision-ventures.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org
Subject: Re: bitkeeper / IDE cleanup
Date: Wed, 06 Mar 2002 15:55:31 +0100 [thread overview]
Message-ID: <3C862DE3.9090404@evision-ventures.com> (raw)
In-Reply-To: <E16icm7-00072w-00@the-village.bc.nu>
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.
next prev parent reply other threads:[~2002-03-06 14:56 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
2002-03-06 14:26 ` Alan Cox
2002-03-06 14:52 ` Alan Cox
2002-03-06 14:55 ` Martin Dalecki [this message]
-- 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=3C862DE3.9090404@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.