Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, 22 May 2001, Jan Harkes wrote: something like, ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen, void *outbuf, size_t outlen); As far as functionality and errors it works like read/write in a single call, pretty much what Richard proposed earlier with a new 'transaction' syscall. Maybe type is not needed, and cmd can be part of the inbuf in which case it would be identical. I'd rather have type and cmd there, simply because right now the cmd passed in to the ioctl is not well-defined, as several different drivers use the same numbers for different things (which is why I want to expand that to type,cmd to get uniqueness). Also, I think the cmd is separate from the data, so I don't think it necessarily makes sense to mix the two. Even if we want to have an ASCII command, I'd think that should be separate from the arguments, ie we'd have ssize_t kioctl(int fd, const char *cmd, const void *inbuf ... instead of trying to mix them. This is especially true as the inbuf would be a user-mode pointer, while cmd would come from kernel space (whether in the form of a type,subcmd number pair or as a kernel string). Linus - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
What is the communication between user space and kernel that transports device identities? It doesn't change, the same symbolic names still work. But today, unless you think of devfs or so, device identities are not transported by symbolic names. They are given by device numbers. [Yes, symbolic names have a certain secondary role, e.g. in error messages, or perhaps to indicate the boot device.] Andries - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 14:43, [EMAIL PROTECTED] wrote: How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition basesizedevicetype Generally, we shouldn't care which order the kernel enumerates devices in or which device number gets assigned internally. If we did need to care, we'd just do: # echo 666 /dev/mypartition/number Only a single thing is of interest. What is the communication between user space and kernel that transports device identities? It doesn't change, the same symbolic names still work. What's happening in my example is, we've gotten rid of the can't-get-there-from-here device naming heirarchy. It should be clear by now that we can't capture 'physical device location' and 'device function' in one tree. So instead, 'physical device' is a property of 'logical device'. The tree is now optional. Note that there is user (human) / user space (programs) / kernel. This user has interesting machinery in his hands, but his programs have only strings (path names, fake or not) to give to the kernel in open() and mount() calls. Now the device path is so complicated that the user is unable to describe it using a path name. devfs made an attempt listing controller, lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is not very attractive, and things only get worse. Yes, we flatten that by making host, bus, target and lun all properties of /proc/ide/hda. Our mistake up to now is that we've tried to carry the logical view and physical view of the device in one name, or equivalently, in path+name. Let the physical device be a property of the logical device and we no longer have our thumb tied to our nose. When I go to a bookshop to buy a book, I can do so without specifying all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, ... A few items suffice. Often the Title alone will do. We want an interface where the kernel exports what it has to offer and the user can pick. Yes, that Zip drive - never mind the bus. But can distinguish - Yes, that USB Zip drive, not the one on the parallel port. 100% agreed. IOW, when the device *does* move we can usually deduce where it's moved to, so lets update the hda's bus location automatically whenever we can (log a message!) and only bother the user about it if it's ambiguous. For good measure, have a system setting that says 'on a scale of 0 to 5, this is how interested I am in being bothered about the fact that a device seems to have moved'. The five minute hack would number devices 1, 2, 3 in order of detection, offer the detection message in /devices/nr/detectionmessage and a corresponding device node in /devices/nr/devicenode. The sysadmin figures out what is what, makes a collection of symlinks with his favorite names, and everybody is happy. Until the next reboot. Or until device removal and addition. There must be a way to give permanence to an association between name and device. Symlinks into a virtual filesystem like /devices are not good enough. Turning the five minute hack into a ten minute hack we take the md5sum of the part of the bootmessage that is expected to be the same the next time we encounter this device and use that as device number. I think a system somewhat in this style could be made to work well. Yes, we are advocating the same thing. I didn't mention that the device properties are supposed to be persistent, did I? If you accept the idea of persistent device properties then the obvious thing to do is to match them up against the detected devices. I didn't want to bring up the persistency thing right away because it begs the question of where you store the persistent data for the root device. Until the namespace issue is resolved this is mainly a distraction. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
`the class of devices in question' was cryptographic devices, and possibly
other transactional DSPs. I don't consider audio to be transactional.
in any case, you can do transactional things with two threads, as long
as they each have their own fd on the device. Think of the fd as your
transaction handle.
Thats a bit pathetic. So I have to fill my app with expensive pthread locks
or hack all the drivers and totally change the multi-open sematics in the ABI
huh?
void thread_init(void) {
int fd = open(/dev/crypto);
real_thread_init(fd);
}
where was that lock again?
and notice this idea is only for transactional things -- what
transactional things do sound drivers do?
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 10:14, Lars Marowsky-Bree wrote: On 2001-05-19T16:25:47, Daniel Phillips [EMAIL PROTECTED] said: How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition base sizedevice type # cat /dev/mypartition/size 1048576 # cat /dev/mypartition/device /dev/sda # mke2fs /dev/mypartition Ek. You want to run mke2fs on a _directory_ ? Could you be specific about what is wrong with that? Assuming that this device directory lives on a special purpose filesystem? If anything, /dev/mypartition/realdev Then every fstab in the world has to change, not to mention adding verbosity to interactive commands. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On 2001-05-19T16:25:47, Daniel Phillips [EMAIL PROTECTED] said: How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition basesizedevice type # cat /dev/mypartition/size 1048576 # cat /dev/mypartition/device /dev/sda # mke2fs /dev/mypartition Ek. You want to run mke2fs on a _directory_ ? If anything, /dev/mypartition/realdev Sincerely, Lars Marowsky-Brée [EMAIL PROTECTED] -- Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, May 21, 2001 at 06:13:18PM -0700, Linus Torvalds wrote: Nope. You can (and people do, quite often) share filps. So you can't associate state with it. For _devices_, though? I don't expect my mouse to work if gpm and xfree both try to consume device events from the same filp. Heck, it doesn't even work when they try to consume events from the same inode :-) I think this is a reasonable restriction for the class of devices in question. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, May 22, 2001 at 02:22:34AM +0200, Ingo Oeser wrote: ioctl has actually 4 semantics: command only command + read command + write command + rw-transaction Separating these would be a first step. And yes, I consider each of them useful. command only: reset drive echo 'reset' /dev/sg0ctl command + rw-transaction: dear device please mangle this data (crypto processors come to mind...) I can't think of a reasonable tool-based approach to this, but I can definitely see that a program could use this well. It simply requires that you use the filp to store your state. fd = open(/dev/crypto) - creates filp write(fd, Death to all fanatics!\n); - calls crypto device, stores result in private data structure sleep(100); read(fd, Qrngu gb nyy snangvpf!\n); - frees data structure [You'll note the advanced design of my crypto processor.] Clearly, this is open to abuse by persons never calling read() and passing in far too much to write(). I think this can be alleviated by refusing to accept more than (say) 4k at a time, or bean-counter. A sick way would be to allow the -write() call to have its buffer modified. But I don't think we want to go down that path. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Hi! 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 read(). As the matter of fact, had been done in userland context for decades. Go and buy Stevens. Read it. Then come back. I don't need to read it. Don't be insulting. Sure, you *can* use a write(2)/read(2) cycle. But that's two syscalls compared to one with ioctl(2) or transaction(2). That can matter to some applications. I just don't think so. Where did you see performance-critical use of ioctl()? Pavel -- I'm [EMAIL PROTECTED] In my country we have almost anarchy and I don't care. Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Alan Cox wrote: Sure. But we have to do two syscalls only if ioctl has both in- and out- arguments that way. Moreover, we are talking about non-trivial in- arguments. How many of these are in hotspots? There is also a second question. How do you ensure the read is for the right data when you are sharing a file handle with another thread.. ioctl() has the nice property that an in/out ioctl is implicitly synchronized I don't think we can generically replace ioctl's with read-write, and we shouldn't bend over backwards even _trying_. The important thing would be to give them more structure, and as far as I'm personally concerned I don't even care if the user-level access method ends up being the same old thing. After all, we have magic numbers everywhere: even a system call uses magic numbers for the syscall entry numbering. The thing that makes system call numbers nice is that the number gets turned into a more structured thing with proper type checking and well-defined semantics very very early on indeed. It shouldn't be impossible to do the same thing to ioctl numbers. Nastier, yes. No question about it. But we don't necessarily have to redesign the whole approach - we only want to re-design the internal kernel interfaces. That, in turn, might be as simple as changing the ioctl incoming arguments of cmd,arg into a structure like type,cmd,inbuf,inlen,outbuf,outlen. Linus - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Alan Cox wrote: Which, BTW, is a wonderful reason for having multiple channels. Instead of write(fd, critical_command, 8); read(fd,); you read from the right fd. Opened before you enter the hotspot. Less overhead than ioctl() would have... The ioctl is one syscall, the read/write pair are two. Im not sure that ioctl is going to be more overhead there. In the video4linux case the high overhead is acking frames received by mmap so might conceivably be considered one way Sure. But we have to do two syscalls only if ioctl has both in- and out- arguments that way. Moreover, we are talking about non-trivial in- arguments. How many of these are in hotspots? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Linus Torvalds wrote:
It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
yes. No question about it. But we don't necessarily have to redesign the
whole approach - we only want to re-design the internal kernel interfaces.
That, in turn, might be as simple as changing the ioctl incoming arguments
of cmd,arg into a structure like type,cmd,inbuf,inlen,outbuf,outlen.
drivers/net/ppp_generic.c:
ppp_set_compress(struct ppp *ppp, unsigned long arg)
{
int err;
struct compressor *cp;
struct ppp_option_data data;
void *state;
unsigned char ccp_option[CCP_MAX_OPTION_LENGTH];
#ifdef CONFIG_KMOD
char modname[32];
#endif
err = -EFAULT;
if (copy_from_user(data, (void *) arg, sizeof(data))
|| (data.length = CCP_MAX_OPTION_LENGTH
copy_from_user(ccp_option, data.ptr, data.length)))
goto out;
And that's far from being uncommon. They _do_ follow pointers. Some - more
than once.
We _will_ have to support ioctls for long. No questions about that. And
there is no magic trick that would work for all of them, simply because
many are too disgusting to be left alive. Let's clean the groups that can
be cleaned and see what's left.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, May 20, 2001 at 12:02:35PM -0700, Linus Torvalds wrote: The problem with ioctl's is, let me repeat, not technology. It's people. ioctl's are a way to do ugly things. That's what they have ALWAYS been. And because of that, people don't care about following the rules - if ioctl's followed the rules, they wouldn't _be_ ioctls in the first place, but instead have a good interface (say, read()/write()). Basically, ioctl's will _never_ be done right, because of the way people think about them. They are a back door. They are by design typeless and without rules. They are, in fact, the Microsoft of UNIX. Yes, they are. Why? Because we cannot fit all behavior of a devices _cleanly_ into read/write/mmap/lseek. If we do, we would need different device views (which implies aliasing of devices, which HPA does not like) and it would still be not that clean, because reading from readonly gives a stream and writing gives a stream too, not particular order required until now. [good points] Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would that make the ugliness explicit and possibly easier to try to manage and fix? Very probably. And it would mean that driver writers could not just say fuck design, I'm going to do this my own really ugly way. Ok, then I give you an real world example where I idly fight with design since nearly 2 years. A free programmable DSP (or set of DSPs) with several kinds of memory and additional optional devices (like DAC/ADC, ISDN frames and sth. like that) on it. This DSP is attached via some glue logic on Parallel port, PCI, ISA or (soon to come) USB. This thingie can (once programmed) act as a data sink, data source or data processing pipe. OTOH it should be randomly accessable via debuggers and program loaders. It is also resettable/rebootable, has discontinous memory of certain kinds (possibly harvard architecture) and many more funny stuff. And it needs to upload software. I try to unify all these stuff into a Generic Processing Device Layer for Linux. Now I like to be shown how I should fit this into clean design that: - uses NO ioctls (Linus) - has only one device per DSP (H.P.A) - Does not emulate ioctls via read/write transactions (which I consider bogus) Theory is nice, but until someone can show me a clean design for this (admittedly heavy ;-)) example, I just don't buy your arguments. A *better* ioctl would be nice, but we still need an catch all exceptional accesses interface, IMNSHO. Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, May 21, 2001 at 05:51:08PM -0400, Alexander Viro wrote: Sure. But we have to do two syscalls only if ioctl has both in- and out- arguments that way. Moreover, we are talking about non-trivial in- arguments. How many of these are in hotspots? ioctl has actually 4 semantics: command only command + read command + write command + rw-transaction Separating these would be a first step. And yes, I consider each of them useful. command only: reset drive command + rw-transaction: dear device please mangle this data (crypto processors come to mind...) The other two are obviously needed and already accepted by all of you. Hotspots: crypto hardware or generally DSPs. Regards Ingo Oeser -- To the systems programmer, users and applications serve only to provide a test load. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Saturday 19 May 2001 13:37, Eric W. Biederman wrote: For creating partitions you might want to do: cat 1024 2048 /dev/sda/newpartition How about: # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap # ls /dev/mypartition base sizedevice type # cat /dev/mypartition/size 1048576 # cat /dev/mypartition/device /dev/sda # mke2fs /dev/mypartition The information that was specified is persistent in /dev. We can rearrange our physical devices any way we want without affecting the name we chose in /dev. When the kernel enumerates devices at startup, our persistent information better match or we will have to take some corrective action. Generally, we shouldn't care which order the kernel enumerates devices in or which device number gets assigned internally. If we did need to care, we'd just do: # echo 666 /dev/mypartition/number setting a persistent device minor number. The major number is inherited via the partition's /device property. To set the minor number back to 'don't care': # rm /dev/mypartition/number By taking the physical device off the top of the food chain we gain the flexibility of being able to move the device from bus to bus for example, and only the partition's device property changes, nothing in our fstab. It's no great leap to set things up so that not even the /device property would need to change. Note that we can have a heirarchy of partitions this way if we want to, since /dev/mypartition is just another block device. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 08:26:20PM -0700, Linus Torvalds wrote:
You're missing the point.
I don't think Richard is actually. I think Richard has hit a nail
dead on its head.
It's ok to do read()/write() on structures.
Ok, we can read()/write() structures. So someone invents the following
structure:
struct foo {
int cmd;
void *data;
} foo;
Now they use write(fd, foo, sizeof(foo)); Haven't they just swapped
the ioctl() interface for write() instead?
Ok, lets hope that humanity isn't that stupid, so lets take another
example:
struct bar {
int in_size;
void *in_data;
int out_size;
void *out_data;
};
struct foo {
int cmd;
struct bar1;
} foo;
Same write call, but ok, we have a structure of known size. Its still
the same problem.
What I'm trying to say is that I think that read+write is open to more
or the same abuse that ioctl has been, not less.
However, it does have one good thing going for it - you can support
poll on blocking ioctls like TIOCMIWAIT.
None of which are network-nice. Basically, ioctl() is historically used
as a pass any crap into driver , and the driver - and ONLY the driver
- will know what to do with it.
I still see read()/write() being a pass any crap interface. The
implementer of the target for read()/write() will probably still be
a driver which will need to decode what its given, whether its in
ASCII or binary.
And driver writers are already used to writing ioctl-like interfaces.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Linus Torvalds wrote: How about moratorium on new ioctls in the meanwhile? Whatever we do in fs/ioctl.c, it _will_ take time. Ehh.. Telling people don't do that simply doesn't work. Not if they can do it easily anyway. Things really don't get fixed unless people have a certain pain-level to induce it to get fixed. Umm... How about the following: you hit delete on patches that introduce new ioctls, I help to provide required level of pain. Deal? BTW, -pre4 got new bunch of ioctls. On procfs, no less. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alexander Viro wrote: On Sun, 20 May 2001, Matthew Wilcox wrote: On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote: Pheeew... Could you spell about megabyte of stuff in ioctl.c? No. $ ls -l arch/*/kernel/ioctl32*.c -rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c -rw-r--r--1 willywilly 109475 May 18 16:39 arch/parisc/kernel/ioctl32.c -rw-r--r--1 willywilly 117605 Feb 1 20:35 arch/sparc64/kernel/ioctl32.c only about 100k. You are missing all x86-only drivers. Now, the point is that it _is_ doable, and by doing it in one standard place (instead of letting each architecture fight it on its own) we'd expose the problem better, and maybe get rid of some of those architecture-specific ones. For example, right now the fact that part of the work _has_ been done by things like Sparc64 has not actually had any advantages: the sparc64 work has not allowed people to say let's try to merge this work, because it has not been globally relevant, and a sparc64-only file has not been a single point of contact that could be used to clean up things. In contrast, a generic file has the possibility of creating new VFS or device-level interfaces. You can catch block device ioctl's and turn them into proper block device requests - and send them down the right request queue. Suddenly a block device driver doesn't just get READ/WRITE requests, it gets EJECT/SERIALIZE requests too. Without having to add magic ioctl's that are specific to just one device driver. So by having a common point of access, you can actually encourage _fixing_ some of the problems. Historically, sparc64 etc have not been able to do that - they can only try to convert different ioctl's into another format and then re-submitting it.. Linus - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alan Cox wrote: Linus, as much as I'd like to agree with you, you are hopeless optimist. 90% of drivers contain code written by stupid gits. ^^^ I think thats a very arrogant and very mistaken view of the problem. 90% of the driver are written by people who are written by != contain code written by. Stuff initally written by sane people tends to get all sorts of crap into it. Unfortunately. The problem being: very few people actually read the code in drivers/*. And crap accumulates. The messier it is, the faster it gets shitted. So relying on the people finding crappy -write() instances and ridiculing the authors in public is... well, somewhat naive. There's more than enough crap already and that simply doesn't happen. It _can_ be done, but it will take more than just having the code sitting there. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
[EMAIL PROTECTED] said: I can tell you haven't had to write any 32-bit ioctl emulation code for a 64-bit kernel recently. If that had been done right the first time, you wouldn't have had to either. For that matter, it's often the case that if the ioctl had been done right the first time, nobody would have had to fix it up for any architecture. I made the mistake of using machine-specific types in some ioctls, but fixed them as soon as I realised some poor sod was going to have to write and maintain the ugly conversion code. For pointers, sometimes it's justified. Often however, as in my case, it was just stupidity on the part of the original coder and should be fixed. Although I suppose I have the advantage that I don't have to worry too much about binary compatibility for the things I changed. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote: Pheeew... Could you spell about megabyte of stuff in ioctl.c? No. $ ls -l arch/*/kernel/ioctl32*.c -rw-r--r--1 willywilly 22479 Jan 24 16:59 arch/mips64/kernel/ioctl32.c -rw-r--r--1 willywilly 109475 May 18 16:39 arch/parisc/kernel/ioctl32.c -rw-r--r--1 willywilly 117605 Feb 1 20:35 arch/sparc64/kernel/ioctl32.c only about 100k. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Ingo Molnar wrote: On Sun, 20 May 2001, Alexander Viro wrote: Linus, as much as I'd like to agree with you, you are hopeless optimist. 90% of drivers contain code written by stupid gits. 90% of drivers contain code written by people who do driver development in their spare time, with limited resources, most of the time serving as a learning excercise. And they do this freely and for fun. Accusing them of being 'stupid gits' is just micharacterising the situation. I would disagree with both of you. The problem is not whether people do it with limited resources or time, or whether they are stupid or not. The problem is that if you expect to get nice code, you have to have nice interfaces and infratructure. And ioctl's aren't it. The reason we _can_ write beautiful filesystems these days is that the VFS layer _supports_ it. In fact, the VFS layer has tons of infrastructure and structure that makes it _hard_ to write bad filesystem code (which is not to say that we don't have ugly code there - but much of it is due to historically not having had quite the same level of infrastructure). If we had nice infrastructure to make ioctl's more palatable, we could probably make do even with the current binary-number interfaces, simply because people would use the infrastructure without ever even _seeing_ how lacking the user-level accesses are. But that absolutely _requires_ that the driver writers should never see the silly pass a random number and a random argument type kind of interface with no structure or infrastructure in place. Because right now even _good_ programmers make a mess of the fact that they get passed a bad interface. Think of it this way: the user interface to opening a file is open() with pathnames and magic flags. But a filesystem never even _sees_ that interface, it sees a very nicely structured setup where all the argument parsing and locking has already been done for it, and the magic flags don't even exist any more as far as the low-level FS is concerned. Which is why filesystems _can_ be clean. In contrast, ioctl's are passed through directly, with no help to make them clean. Linus - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
How about sprintf(s + strlen(s), foo)? Solar Designer said two years ago we should be using snprintf in the kernel. He was most decidedly right 8) - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Linus, as much as I'd like to agree with you, you are hopeless optimist. 90% of drivers contain code written by stupid gits. I think thats a very arrogant and very mistaken view of the problem. 90% of the driver are written by people who are - Copying from other drivers - Using the existing API's to make their job easy - Working to timescales - Just want it to work So if you take ioctl away from them they will implement ioctl emulation by writing ioctl structs to an fd. If you want to make these things work well you have to provide a good working infrastructure. You don't change anything (except the maintainer) by causing pain. Instead you provide the mechanisms - the generic parsing code so that people don't screw up on procfs parsing - the generic ioctl alternatives etc. Ditto with the major numbers. You win that battle by getting enough people to believe it is the right answer that they write the nice code for managing resources and naming assignment - which is already beginning to occur. Then even if I'm still maintaining a major number list in 2 years nobody can quite remember why, and people are heard murmering 'You should have tried Linux two years ago, you had to actually make device files yourself sometimes' Alan - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Russell King wrote: I still see read()/write() being a pass any crap interface. The implementer of the target for read()/write() will probably still be a driver which will need to decode what its given, whether its in ASCII or binary. And driver writers are already used to writing ioctl-like interfaces. You _are_ missing the point. write() doesn't have that history of wild abuse. It's easier to whack the driver writer's balls for abusing it. I'm more than willing to play Narn Bat Squad and I'm pretty sure that I'm not alone at that. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote: Nobody will expect the above to work, and everybody will agree that the above is a BUG if the read() call will actually follow the pointer. I didn't say anything about read(). I said write(). Obviously it wouldn't work for read()! Read my email. And read the last line: psychology is important. I did. I also know that if you give the world enough rope, someone will hang themselves. (Note that because I've thought a way of misusing this in the same was as ioctl, you can bet your bottom dollar that other people will). -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
[EMAIL PROTECTED] said:
Now, a good way to force the issue may be to just remove the ioctl
function pointer from the file operations structure altogether. We
don't have to force peopel to use read/write - we can just make it
clear that ioctl's _have_ to be wrapped, and that the only ioctl's
that are acceptable are the ones that are well-designed enough to be
wrappable. So we'd have a linux/fs/ioctl.c that would do all the
wrapping,
I have so far resisted adding an 'ioctl' method to the MTD structure. Yet
because userspace needs to be able to request an erase, request information
about the erasesize of the device, etc., I've got an ioctl wrapper much as
you describe in drivers/mtd/mtdchar.c. It calls _real_ functions like
-erase() in the underlying MTD device, which can't easily be exposed to
userspace (unless we do something silly like using CORBA :)
I can see the advantage of doing what you suggest - add methods to the
struct block_device for the sensible things like HDIO_GETGEO, BLKGETSIZE,
etc. (and anyone suggesting that it's sensible to have the physical block
device driver at all involved in BLKRRPART shall be summarily shot).
But please don't _actually_ put all the ioctl wrappers in fs/ioctl.c. It'd
be a nightmare for the maintainers of the various sections of it.
Besides, what on earth does it have to do with file systems?
Maybe abi/ioctl/{blkdev,mtd,usb,scsi,...}.c ?
Having it outside the directories which are traditionally owned by the
respective subsystem maintainers means that it's far easier to be fascist
about what's added, too.
On a related note - I was actually beginning to consider a dev-private ioctl
for MTD devices, actually for reasons of taste - some stuff like turning
on/off the automatic hardware ECC on the DiskOnChip devices I consider ugly
enough that I didn't want to deal with it in generic code. At least a
dev-private ioctl seemed like it would banish the ugliness into the
offending driver, and be vaguely reusable if any other device turned out to
require such ugliness.
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Alexander Viro wrote: Linus, as much as I'd like to agree with you, you are hopeless optimist. 90% of drivers contain code written by stupid gits. 90% of drivers contain code written by people who do driver development in their spare time, with limited resources, most of the time serving as a learning excercise. And they do this freely and for fun. Accusing them of being 'stupid gits' is just micharacterising the situation. People do not get born as VFS hackers, there is a very steep learning curve, and only a few make it to to have knowledge like you. Much of the learning curve of various people has traces in drivers/*, it's more like the history of Linux then some coherent image of people's capabilities. Ingo - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sun, 20 May 2001, Russell King wrote: On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote: Nobody will expect the above to work, and everybody will agree that the above is a BUG if the read() call will actually follow the pointer. I didn't say anything about read(). I said write(). Obviously it wouldn't work for read()! No, but the point is, everybody _would_ consider it a bug if a low-level driver write() did anything but touched the explicit buffer. Code like that would not pass through anybody's yuck-o-meter. People would point fingers and say That is not a legal write() function. Anybody who tried to make write() follow pointers would be laughed at as a stupid git. Anybody who makes ioctl() do the same is just following years of standard practice, and the yuck-o-meter doesn't even register. THAT is the importance of psychology. Technology is meaningless. What matters is how people _think_ of it. Linus - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 better than special names. What about partition editing on other OSs? There's no reason why fdisk/parted/etc. should be Linux only. Why should the kernel need to know how to write partition tables? It needs to read them. Writing doesn't add much. Wrong. When you read, you throw out 90% of the useless crap. When you write, you need to know about it, and provide interfaces for it. I'd rather see trivial partitioning tools that consist only of UI code in case of Linux. Some stuff friendly partition tools should have, IMHO: (1) ability to predict what's going to happen. That way, you can play around until it looks nice, and hit the friendly commit button. (2) ability to do data recovery (eg: probe for signatures where it expects the start of partitions to occur. You can be intelligent/quick about it, by knowing about alignment stuff, for example) (3) ability to convert between partition table types (and even LVM ;-) This can be tricky because of alignment stuff. So: (1) could be done in-kernel by being able to discard changes, and re-reading, I guess. (2) and (3) really only need alignment stuff. Also, you need to be able to deal with legacy stuff, like setting magic flags for booting. Also, different partition table formats have different alignment constraints (which is relevant for creating partitions). These mainly need to be respected for other braindead OS's and/or BIOSes. Communicating those between user/kernel space doesn't excite me. So don't communicate them. So, what do you do? Sometimes, you want to force alignment violations (eg: recovering an accidently deleted partition) The real problem happens when you want to resize file systems, and you need to simultaneously satisfy resizer and partition table constraints. (there are currently no resizers like this, but an ext2-resize-the-start and NTFS-resize-the-start would definitely be like this... when I get time to write them. It's pure luck that you don't need this for FAT, but this causes all sorts of headaches for Linux...) Anyway, you have one constraint in user space, and one in the kernel... how do you find the intersection? Libtool friends deals with version skew (ugly, but it works...) With statically linked binaries? How? Why do we need them? You can write wrappers for libraries. Uh-huh. And you can write them for ioctls. We had been busily doing that for years. Results are not pretty, to put it very mildly. If you can get everything into a nice file system interface, then you've convinced me. BTW, most of the code can very well sit in the userland, but that's another story (userland filesystems). Anyway, there's only one way to settle such stuff - sit down and write the patch. Which is what I'm going to do. Have fun. So, my patch will be about 50 lines in parted, to call blkpg, and provide a kernelread command... But, philosophy essay to write... :-( (you have to wait until Monday) Then you can rm -r fs/partitions But, I don't see how patches will settle anything, when we're arguing over interfaces stuff needed for partition tools. Or are you writing patches for Parted as well? Andrew Clausen - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 with initrd. Probably most systems are the same. It seems a step backward to make it necessary. Well, if you remove partition table parsing from the kernel - you've got to boot with root on unpartitioned device (e.g. /dev/ram0) and either stay that way or bring the userland code that understands partitioning on that device... - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 implemented by write() and read(). As the matter of fact, had been done in userland context for decades. Go and buy Stevens. Read it. Then come back. I don't need to read it. Don't be insulting. Sure, you *can* use a write(2)/read(2) cycle. But that's two syscalls compared to one with ioctl(2) or transaction(2). That can matter to some applications. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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, there wouldn't be any practical gain, since we already have ioctl(2). Any gain would be aesthetic. I can tell you haven't had to write any 32-bit ioctl emulation code for a 64-bit kernel recently. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 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? 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. If you've ever seen the way some of the bootloaders for alterate platforms (like ppc and 68k) handle booting, you'd see what a pain it can be to have anything more than a simple string of options getting passed to the kernel. It's particularly bad on some of the embedded ppc platforms. I suspect that if this happened, it would never be allowed into many people's trees, because it would be worth their effort to maintain different code so they don't have to squeeze an initrd on flash along with their kernel and root filesystem. If I'm missing the boat here, please tell me, but it sure seems like a bad idea to me. Brad Boyer - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 aren't shown in directory listings is plain evil. I really don't want to explain why. It's extremely messy and unintuitive. It would be better to do this with a file that does exist, for example writing something to /proc/disks/sda/arguments. Then again, I don't even think much of dynamic file systems in the first place. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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, size_t wlen); Of course, there wouldn't be any practical gain, since we already have ioctl(2). Any gain would be aesthetic. I can tell you haven't had to write any 32-bit ioctl emulation code for a 64-bit kernel recently. 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 easily. The main advantage of transaction(2) is that hopefully, people will not be so bone-headed as to forget to pass sizeof *structptr as the size field. So perhaps some error trapping is possible. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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. Alan - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 read(). As the matter of fact, had been done in userland context for decades. Go and buy Stevens. Read it. Then come back. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
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 prefer a different command set. Well... Around here we've been used to Microsoft translations like: ETES-VOUS CERTAIN [O/N] ? ... and of course pressing 'o' doesn't work while 'y' does. :-) Wanting to localize such low-level keywords is utopia. Otherwise you'll want to translate command names like free, rm, mv, etc. and yet programming languages as well like C keywords. And then you come to a point where nothing could be interoperable any more. Nicolas - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
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-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 seems a step backward to make it necessary. - - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
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 not notice the difference as a user, as a sysadmin, as a kernel builder, as a kernel hacker, or all of the above? All of the above. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED]
