Alexander Viro wrote:
ioctls are evil, period. At least with these names you can use normal
scripting and don't need any special tools. Every ioctl means a binary
that has no business to exist.
Special names are butt-ugly.
ioctl's can be replaced with games on /proc or whatever, which are
On Sat, 19 May 2001, Andrew Morton wrote:
Alexander Viro wrote:
(2) what about bootstrapping? how do you find the root device?
Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty.
Ben's patch makes initrd mandatory.
Can this be fixed? I've *never* had to futz
Here's a dumb question, and I apologize if I am questioning computer
science dogma...
Why are LVM and EVMS(competing LVM project) needed at all?
Surely the same can be accomplished with
* md
* snapshot blkdev (attached in previous e-mail)
* giving partitions and blkdevs the ability to grow and
Alexander Viro wrote:
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
1) opening /dev/zero/start_nuclear_war has a certain side effect.
2) Local user does the following:
ln -sf /dev/zero/start_nuclear_war bar
[EMAIL PROTECTED] wrote:
Hmm. You know that I wrote this long ago?
Well, let's not get too hung up on the disk thing (yeah,
I started it...).
Ben's intent here is to *demonstrate* how argv-style
info can be passed into device nodes. It seems neat,
and nice.
We can also make use of a strong
On Sat, 19 May 2001, Ben LaHaise wrote:
1. Generic lookup method and argument parsiing (fs/lookupargs.c)
Looks sane.
2. Restricted block device (drivers/block/blkrestrict.c)
This is not very user-friendly, but along with symlinks this makes perfect
sense. It would make partition handling
Alexander Viro writes:
On Sat, 19 May 2001, Richard Gooch wrote:
The transaction(2) syscall can be just as easily abused as ioctl(2) in
this respect. People can pass pointers to ill-designed structures very
Right. Moreover, it's not needed. The same functionality can be
trivially
On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
Al, if you really want to kill ioctl(2), then perhaps you should
implement a transaction(2) syscall. Something like:
int transaction (int fd, void *rbuf, size_t rlen,
void *wbuf, size_t wlen);
Of course,
On Sun, 20 May 2001, Ingo Oeser wrote:
PS: English is neither mine, nor Linus native language. Why do
the English natives complain instead of us? ;-)
Because we had some experience with, erm, localized systems and for
Alan it's most likely pure theory? ;-)
I think its important its
On Sat, May 19, 2001 at 10:22:55PM -0400, Richard Gooch wrote:
The transaction(2) syscall can be just as easily abused as ioctl(2) in
this respect.
But read() and write() cannot.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line unsubscribe
Alexander Viro writes:
Folks, before you get all excited about cramming side effects
into open(2), consider ...
I agree completely.
A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree.
On Sat, 19 May 2001, Jeff Garzik wrote:
Are we talking about device arguments just for chrdevs and blkdevs?
(ie. drivers) or for regular files too?
Let's distinguish between per-fd effects (that's what name in open(name, flags)
is for - you are asking for descriptor and telling what
Aaron Lehmann wrote:
On Sat, May 19, 2001 at 08:05:02PM +0200, [EMAIL PROTECTED] wrote:
initrd is an unnecessary pain in the ass for most people.
It had better not become mandatory.
You would not notice the difference, only your kernel would be
a bit smaller and the RRPART ioctl
Abramo Bagnara wrote:
Alexander Viro wrote:
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
1) opening /dev/zero/start_nuclear_war has a certain side effect.
[...]
Can't this easily avoided if the needed action is not
On Sat, 19 May 2001, Ben LaHaise wrote:
It's not done yet, but similar techniques would be applied. I envision
that a raid device would support operations such as
open(/dev/md0/slot=5,hot-add=/dev/sda)
Think for a moment and you'll see why it's not only ugly as hell, but simply
won't
On Sat, May 19, 2001 at 06:48:19PM +0200, Erik Mouw wrote:
One of the fundamentals of Unix is that everything is a file and that
you can do everything by reading or writing that file.
But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see
if it's there. writing to files that
Matthew Wilcox writes:
On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
Al, if you really want to kill ioctl(2), then perhaps you should
implement a transaction(2) syscall. Something like:
int transaction (int fd, void *rbuf, size_t rlen,
void *wbuf,
On Sat, 19 May 2001, Abramo Bagnara wrote:
Can't this easily avoided if the needed action is not
/dev/zero/start_nuclear_war
or
/dev/zero/start_nuclear_war
but
echo I'm evil /dev/zero/start_nuclear_war
Sure. And that's the right thing to do (not the implied action, that is -
ioctls are evil, period. At least with these names you can use normal
scripting and don't need any special tools. Every ioctl means a binary
that has no business to exist.
That is not IMHO a rational argument. It isn't my fault that your shell does
not support ioctls usefully. If you used
On Sat, May 19, 2001 at 12:51:07PM -0400, Alexander Viro wrote:
clone(), walk(), clunk(), stat() and open() ;-) Basically, we can add
unopened descriptors. I.e. no IO until you open it (turning the thing into
opened one), but we can do lookups (move to child), we can clone and
kill them and
On Sat, 19 May 2001, Richard Gooch wrote:
The transaction(2) syscall can be just as easily abused as ioctl(2) in
this respect. People can pass pointers to ill-designed structures very
Right. Moreover, it's not needed. The same functionality can be trivially
implemented by write() and
On Sat, 19 May 2001, Alexander Viro wrote:
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
Your argument is stupid, imnsho.
Side-effects are perfectly fine if they are _local_ to the file
descriptor. Your example is contrieved
On Sat, 19 May 2001, Andrew Morton wrote:
So. When am I going to be able to:
open(/bin/ls,-l,/etc/passwd, O_RDONLY);
You are not. Think for a minute and you'll see why.
Linus' idea of /dev/tty/parameters is marginally sane - it makes sense
to consider that as
Are we talking about device arguments just for chrdevs and blkdevs?
(ie. drivers) or for regular files too?
Speaking about drivers specifically, a controlling miscdev, one per
device or one per group of devices depending on your needs, is a much
more clean solution for passing ioctl-type data.
On Sun, 20 May 2001, Ingo Oeser wrote:
PS: English is neither mine, nor Linus native language. Why do
the English natives complain instead of us? ;-)
Because we had some experience with, erm, localized systems and for
Alan it's most likely pure theory? ;-)
On Sat, May 19, 2001 at 05:25:22PM +0100, Alan Cox wrote:
Only to an English speaker. I suspect Quebec City canadians would prefer a
different command set.
Should we support `pas387' as well as `no387' as a kernel boot parameter
then? Face it, a sysadmin has to know the limited subset of
Linus Torvalds wrote:
There are some strong arguments that we should have filesystem
backdoors for maintenance purposes, including backup.
I think I agree with something Al said over IRC, that fs-level snapshots
are preferred over block level snapshots.
fs-level snapshots should become easy
On Sat, 19 May 2001, Alan Cox wrote:
Now that I'm awake and refreshed, yeah, that's awful. But
echo hot-add,slot=5,device=/dev/sda /dev/md0/control *is* sane. Heck,
the system can even send back result codes that way.
Only to an English speaker. I suspect Quebec City canadians would
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree. Unfortunately this is false.
Opening device files often has interesting side effects.
initrd is an unnecessary pain in the ass for most people.
It had better not become mandatory.
You would not notice the difference, only your kernel would be
a bit smaller and the RRPART ioctl disappears.
[Besides: we have lived with DOS-type partition tables for ten years,
but they will not
On Sat, 19 May 2001, Ben LaHaise wrote:
On Sat, 19 May 2001, Alexander Viro wrote:
On Sat, 19 May 2001, Ben LaHaise wrote:
It's not done yet, but similar techniques would be applied. I envision
that a raid device would support operations such as
Alexander Viro wrote:
(2) what about bootstrapping? how do you find the root device?
Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty.
Ben's patch makes initrd mandatory.
Can this be fixed? I've *never* had to futz with initrd.
Probably most systems are the same. It
Opening device files often has interesting side effects.
Too bad. They can be triggered by similar races between attacker
changing the type of object (file-symlink) and backup.
Yes. This is a well-known security problem.
Doing
stat(file, s);
if (action desired) {
From [EMAIL PROTECTED] Sat May 19 20:07:23 2001
initrd is an unnecessary pain in the ass for most people.
It had better not become mandatory.
You would not notice the difference, only your kernel would be
a bit smaller and the RRPART ioctl disappears.
Would I
Alexander Viro wrote:
It's way past ugly.
I knew you'd like it.
It kind of makes sense, because it puts the two primary stream-of-bytes
objects in Unix into the same namespace, with the same accessors.
So if some random application is expecting a filename well heck, you
just give it a
35 matches
Mail list logo
