Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Aaron Lehmann
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 disappears. Would I not

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Jeff Garzik
Jeff Garzik wrote: Notice also a metadata miscdev solves the problem of passing options on open -- just pass those options to the miscdev before you open it... to be more clear, it == the data device, not the metadata miscdev -- Jeff Garzik | Do you have to make light of everything?!

Re: [RFD w/info-PATCH] device arguments from lookup, partion codein userspace

2001-05-19 Thread Alexander Viro
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

2001-05-19 Thread Matthew Wilcox
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

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Alexander Viro
On Sat, 19 May 2001, Matthew Wilcox wrote: 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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Alexander Viro
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion codeinuserspace

2001-05-19 Thread Linus Torvalds
On Sat, 19 May 2001, Brad Boyer wrote: If I understand the status of stuff correctly, I think this would make it a lot more painful to admin if it became a requirement to use initrd on everything just to be able to boot. Don't get too hung up on initrd. Symbolic links really _are_ workable

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Linus Torvalds
On Sat, 19 May 2001, Alexander Viro wrote: On Sun, 20 May 2001, Edgar Toernig wrote: That assumption is totally bogus. Even for regular files you have side effects (atime); for anything else they're unpredictable. That means only one thing: safe backups are possible only in

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup)

2001-05-19 Thread Andries . Brouwer
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) {

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Linus Torvalds
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

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Jeff Garzik
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.

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Ben LaHaise
On Sat, 19 May 2001, Andrew Clausen wrote: (1) these issues are independent. The partition parsing could be done in user space, today, by blkpg, if I read the code correctly ;-) (there's an ioctl for [un]registering partitions) Never tried it though ;-) I tried to imply that through the

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Richard Gooch
Andries Brouwer writes: Andrew Morton writes: (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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Ben LaHaise
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 open(/dev/md0/slot=5,hot-add=/dev/sda) Think for a moment and you'll see why

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Andries . Brouwer
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

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Edgar Toernig
nitpicking: a system call without side effects would be pretty useless. Alexander Viro 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). That assumption is totally bogus. Even for regular files you have side

Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Alexander Viro
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 while true; do

RTL8139 difficulties in 2.2, not in 2.4

2001-05-19 Thread Matthias Andree
Hi, I'm having difficulties with a RTL8139 with Linux 2.2.19 (both drivers), but not with Linux 2.4.4's 8139too driver. The card is an Allied Telesyn AT-2500TX, the chip is reported as 8139C/rev. 0x10. The card shares its IRQ 9 with an nVidia Riva TNT 128 [NV04], rev. 4. (eth0 is a 3C900 Combo

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Alexander Viro
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 -

Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace

2001-05-19 Thread Andrew Morton
[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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Alexander Viro
On Sat, 19 May 2001, Andrew Clausen wrote: (1) these issues are independent. The partition parsing could be done in user space, today, by blkpg, if I read the code correctly ;-) (there's an ioctl for [un]registering partitions) Never tried it though ;-) ioctls are even more evil than

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup)

2001-05-19 Thread Matthew Wilcox
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

2001-05-19 Thread Erik Mouw
On Sat, May 19, 2001 at 03:02:47PM +0100, Alan Cox 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. That is not IMHO a rational argument. It isn't my fault

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Alexander Viro
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion codein userspace

2001-05-19 Thread Andrew Morton
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace

2001-05-19 Thread Aaron Lehmann
On Sat, May 19, 2001 at 01:30:14PM +0200, [EMAIL PROTECTED] wrote: I don't think so. It is necessary, and it is good. But it is easy to make the transition painless. Instead of the current choice between INITRD (yes/no) we have INITRD (default built-in / external). The built-in version can

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-19 Thread Alexander Viro
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

2001-05-19 Thread Alan Cox
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

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

2001-05-19 Thread Alexander Viro
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? ;-)

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

2001-05-19 Thread Alan Cox
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 prefer a different command set. - To

<    1   2   3   4