Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 notice the difference as a user, as a sysadmin, as a kernel builder, as a kernel hacker, or all of the above? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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?! Building 1024| I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion codein userspace
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 configuring-upon-open. You _are_ going to do IO on that file. Ben's /dev/md0/living_horror is ugly - it's open just for side effects, with no IO supposed to happen. His idea of passing file descriptor instead of name makes these side effects even messier. The stuff you've proposed is a perversion worth of Albert. You've introduced additional metacharacter into filenames, you will need some form of quoting to be able to pass literal commas and you will need to quote slashes. It's way past ugly. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 english which is used to configure a kernel. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 (move to child), we can clone and kill them and we can stat them. Those who would like a more detailed explanation can find one at http://plan9.bell-labs.com/sys/man/5/INDEX.html Umm... Yes, it's an allusion to 9P, but no, I'm not serious about exporting that to userland. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 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 work. Yeah, I shouldn't be replying to email anymore in my bleery-eyed state. =) Of course slash seperated data doesn't work, so it would have to be hot-add=filedescriptor or somesuch. Gah, that's why the options are all parsed from a single lookup name anyways... That's why you want to use write(2) to pass that information instead of encoding it into open(2). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion codeinuserspace
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 ways to basically cache the information across boots, and the real problems are elsewhere. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 single-user mode. There are some strong arguments that we should have filesystem backdoors for maintenance purposes, including backup. You can, of course, so parts of this on a LVM level, and doing backups with disk snapshots may be a valid approach. However, even that is debatable: there is very little that says that the disk image has to be up-to-date at any particular point in time, so even with a disk snapshot capability (which is not necessarily reasonable under all circumstances) there are arguments for maintenance interfaces. Thinks like lazy fsck (ie fsck while already running the filesystem) and defragmentation simply is not feasible on a LVM level. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup)
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) {
action(file);
}
is no good because there is a race.
But doing
fd = open(file, flags);
fstat(fd, s);
if (action desired) {
f_action(fd);
}
is no good either because the open() has unknown side effects.
It helps to add flags like O_NONBLOCK and perhaps O_NOCTTY,
but that is not quite good enough.
One would like to have a version of the open() call that was
guaranteed free of side effects, and gave a fd only -
perhaps for stat(), perhaps for ioctl().
This guarantee could perhaps be obtained by omitting the
f-f_op-open(inode,f);
call in dentry_open() when the open call is
open(file, O_FDONLY);
Of course it may be that we afterwards decide that fd must
be used, and then it needs upgrading:
fd = f_open(fd, O_RDWR);
Andries
[Such a construction allows various cleanups.
But no doubt it has problems that I have not yet thought of.]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 and idiotic. Filename extensions would not replace ioctl's. But they are wonderful ways to avoid unnecessary binary name-spaces, like the ones we have with callout TTY names, and the one that the fb people had. For example, do a ls -l /dev/fd0*, and ponder. Also, realize that we have these hard-coded names in _addition_ to the magic ioctl to set even more parameters. These are all stupid and bad, and it would have been a _lot_ cleaner to be able to do open(/dev/fd0/H1440, O_RDWR).. or open(/dev/fd0/HD,18,85, O_RDWD) to open special non-standard high-density modes. We already did this, in a very limited and stupid way, by encoding the minor number and generating a standard naming scheme. We can do the same thing in a _much_ more generic way by just realizing that we wanted the open to be name-based in the first place. These are _not_ side effects. They are very much naming conventions. If I want to open a the floppy in one of the special extended modes, it makes a LOT more sense to just open it with the naming, than to open a generic floppy device only to them use a magic and very unreadable ioctl to set the mode of the device. In short, I don't buy your arguments for one single second. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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. You are free to come up with whatever method of communication with the driver is most efficient for your needs -- without perverting open(2). Notice also a metadata miscdev solves the problem of passing options on open -- just pass those options to the miscdev before you open it... metadata miscdevs are a clean solution to what procfs hacks and ioctls are trying to accomplish. Jeff -- Jeff Garzik | Do you have to make light of everything?! Building 1024| I'm extremely serious about nailing your MandrakeSoft | step-daughter, but other than that, yes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 use of the the word component. Yes, they're independant, but the code is pretty meaningless without a demonstration of how it's used. ;-) (2) what about bootstrapping? how do you find the root device? Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty. root= becomes a parameter to mount, and initrd becomes mandatory. I'd be all for including all of the bits needed to build the initrd boot code in the tree, but it's completely in the air. (3) how does this work for LVM and RAID? 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) (4) propagandalibparted already has a fair bit of partition scanning code, etc. Should be trivial to hack it up... That said, it should be split up into .so modules... 200k is a bit heavy just for mounting partitions (most of the bulk is file system stuff). /propaganda Good. Less work to do. (5) what happens to /etc/fstab? User-space ([u]mount?) translates /dev/hda1 into /dev/hda/offset=63,limit=1235823, and back? I'd just create a symlink to /dev/hda1 at mount time, although that really isn't what the user wants to see: the label or uuid is more useful. -ben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 initrd. Probably most systems are the same. It seems a step backward to make it necessary. I don't think so. It is necessary, and it is good. It most certainly is not. This attitude of pushing more and more stuff out of the kernel and into initrd is really annoying. Initrd is messy, nasty and opaque. It makes the boot process more complex. There is no way in hell I want to be forced to use it. Removing N lines from the kernel at the cost of adding N+k lines to user-space is a *loss*, not a gain. I want my *system* to be simple and transparent. But it is easy to make the transition painless. No, initrd is fundamentally painful. Let go of this ideology of removing code from the kernel at all costs. A super-slim kernel which requires a more complex to administer user-space is too high a cost. The benefits of removing partition support from the kernel are basically zero. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 it's not only ugly as hell, but simply won't work. Yeah, I shouldn't be replying to email anymore in my bleery-eyed state. =) Of course slash seperated data doesn't work, so it would have to be hot-add=filedescriptor or somesuch. Gah, that's why the options are all parsed from a single lookup name anyways... -ben (who's going to sleep) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 last another ten years. Very soon disk partitions will look very different. It will be good to move knowledge about these things out of the kernel before this happens.] Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 effects (atime); for anything else they're unpredictable. Ciao, ET. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 mkdir foo rmdir foo ln -sf bar foo rm foo done 3) Comes the night and root runs (from crontab) updatedb(8). Said beast includes find(1). With sufficiently bad timing find _will_ be tricked into attempt to open foo. It will honestly lstat() it, all right. But there's no way to make sure that subsequent open() on the found directory will get the same object. 4) Side effect happens... Similar scenarios can be found for other programs run by/as root, but I think that the point is obvious - side effects on open() are not a good idea. Yes, we can play with checking for O_DIRECTORY, yodda, yodda, but I wouldn't bet a dime on security of a system with such side effects. 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). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTL8139 difficulties in 2.2, not in 2.4
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 with 10base2 network) The card is connected to a Siemens DSL modem which Deutsche Telekom AG provides me with, mii-diag claims that modem refuses auto-negotiation, the modem officially talks 10BaseT, not sure if half or full duplex. This is the 8139/8129 driver of 2.2.19 speaking (note updating that to the scyld.com v1.13 driver doesn't help): eth1: RealTek RTL8139 Fast Ethernet at 0xbc00, IRQ 9, [MAC NOT SHOWN] ... eth1: Transmit timeout, status 0d 0004 media 18. eth1: Tx queue start entry 44 dirty entry 40. eth1: Tx descriptor 0 is 9008a06e. (queue head) eth1: Tx descriptor 1 is 9008a06e. eth1: Tx descriptor 2 is 9008a06e. eth1: Tx descriptor 3 is 9008a06e. eth1: MII #32 registers are: 1000 782d 01e1 . ... eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: RTL8139 Interrupt line blocked, status 5. eth1: RTL8139 Interrupt line blocked, status 5. eth1: RTL8139 Interrupt line blocked, status 4. eth1: RTL8139 Interrupt line blocked, status 4. (continues every minute with status 4 if no traffic on interface) The 8139too driver with 2.2.19 reports this: eth1: Setting half-duplex based on auto-negotiated partner ability . eth1: Tx queue start entry 44 dirty entry 40. eth1: Tx descriptor 0 is 2000. (queue head) eth1: Tx descriptor 1 is 2000. eth1: Tx descriptor 2 is 2000. eth1: Tx descriptor 3 is 2000. eth1: Setting half-duplex based on auto-negotiated partner ability . no mentionings about 8139 IRQ difficulties with 8139too. There has been a similar report in the German-language t-online.zugang.adsl newsgroup. 2.4.4 only has the Setting half-duplex log entry, no more eth1 log entries, and is working properly. Here's a diff from the rtl8139-diag v1.01 output, from 2.2 to 2.4: --- 8139-2.2Sat May 19 11:01:20 2001 +++ 8139-2.4Sat May 19 12:28:24 2001 @@ -1,12 +1,12 @@ rtl8139-diag.c:v1.01 4/30/99 Donald Becker ([EMAIL PROTECTED]) Index #1: Found a RealTek RTL8139 adapter at 0xbc00. RealTek chip registers at 0xbc00 - 0x000: 3d843000 c29c 8000 9008a0f8 9008a0c6 9008a0c6 9008a0fe - 0x020: 0732a000 0732a600 0732ac00 0732b200 0730 0d0a 00cc00bc c07f - 0x040: 74000400 9c0e d5a60770 002c10c6 008cc118 0010 + 0x000: 3d843000 c29c 9008a03c 9008a03e 9008a03c 9008a062 + 0x020: 038f2000 038f2600 038f2c00 038f3200 06a3 0d0a 41b441a4 c07f + 0x040: 74000600 0200f78a c5903fe1 000d10c6 0088d118 0010 0x060: 1000f00f 01e1782d 0005 000f77c0 b0f243b9 7a36d743. No interrupt sources are pending. - The chip configuration is 0x10 0x2c, MII half-duplex mode. + The chip configuration is 0x10 0x0d, MII half-duplex mode. Parsing the EEPROM of a RealTek chip: PCI IDs -- Vendor 0x10ec, Device 0x8139, Subsystem 0x1259. PCI timer settings -- minimum grant 32, maximum latency 64. Can someone help? -- Matthias Andree - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 - _that_ would be too messy). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
[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 argument parsing library in the kernel - there are a great number of open-coded string bashing functions which could be rationalised and regularised. So. When am I going to be able to: open(/bin/ls,-l,/etc/passwd, O_RDONLY); ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 encoding limits into the name. Cease and desist, please. (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. (3) how does this work for LVM and RAID? It doesn't (4) propagandalibparted already has a fair bit of partition scanning code, etc. Should be trivial to hack it up... That said, it should be split up into .so modules... 200k is a bit heavy just for mounting partitions (most of the bulk is file system stuff). /propaganda We will be much better off providing a sane API from the kernel. And dropping the layout-aware code from fdisk, parted, yodda, yodda. Libraries do not remove code duplication. You still need to relink the stuff you keep statically linked, etc. Otherwise you get version skew. Big way. Besides, you can't use library from a script, etc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup)
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 we can stat them. Those who would like a more detailed explanation can find one at http://plan9.bell-labs.com/sys/man/5/INDEX.html -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 that your shell does not support ioctls usefully. If you used perl as your login shell you would have no problem there. Sure, you're right, but Al's point is that you shouldn't need to. One of the fundamentals of Unix is that everything is a file and that you can do everything by reading or writing that file. The devices are the big exception, they need ioctls to control them. With Al's proposal we can get rid of the ioctls and let the devices behave like normal files. Erik [who remembers a discussion like this years ago on comp.os.linux.kernel with similar conclusion: ioctls are bad, we should get rid of them] -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 work. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion codein userspace
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 path-to-executable with args. It won't care, although it may have trouble lseek()ing on it. It wasn't very serious at all. - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 then slowly become smaller and die. initrd is an unnecessary pain in the ass for most people. It had better not become mandatory. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
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 behaviour do you want for IO on it) and system-wide side effects. IMO encoding the former into name is perfectly fine, and no write on another file can be sanely used for that purpose. For the latter, though, we need to write commands into files and here your miscdevices (or procfs files, or /dev/foo/ctl - whatever) is needed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 considered. I do like the idea of a sensible ioctl encoding (including ascii potentially) and being able to ship ioctls over the network. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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? ;-) Al, still shuddering at the memories - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
