Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sun, 20 May 2001, Abramo Bagnara wrote: > I've just had a "so simple to risk to be stupid" idea. > > To have /proc/self/fd/N/ioctl would not have the potential to suppress > ioctl needs for *all* current uses? No, it wouldn't. For one thing, it messes the only half-decent part of procfs. For another, the real issue is how to eliminate the bogus ioctls from userland programs and what to replace them with. Crappy API won't become better if you simply change the calling conventions. And problem with ioctls is that most of them are crappy APIs. Coming from authors' laziness and/or debility. So there is no easy way to solve that stuff - we'll need to rethink tons of badly designed interfaces. Finding a way to represent them in fs is the least of the problems. And we really need to rethink them. Repackaged shit remains shit and the whole point of exrecise is to get rid of it, not to shove it into a new pile. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Alexander Viro wrote: > > On Sat, 19 May 2001, Linus Torvalds wrote: > > > > > What you're really proposing is to make ioctl's be ASCII strings. > > > > Which is not necessarily a bad idea, and I think plan9 did something > > similar (or rather, if I remember correctly, plan9 has control streams > > that were ASCII. Or am I confused?). > > You are not. Control streams in question look like normal files. Normally > driver exports a tree with several data files (e.g. fd0, fd1, fd2, fd3) > and several control files (e.g. fd0ctl, fd1ctl, fd2ctl, fd3ctl). write() > to the latter passes commands. No extra syscalls needed. I've just had a "so simple to risk to be stupid" idea. To have /proc/self/fd/N/ioctl would not have the potential to suppress ioctl needs for *all* current uses? -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good! - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sat, 19 May 2001, Pavel Machek wrote: > I thought about how to do networking without sockets, and it seems to > me like this kind of modify syscall is needed, because network sockets > connect to *two* different places (one local address and one > remote). Sockets are really nasty :-(. Pavel, take a look at http://plan9.bell-labs.com/sys/man/3/ip - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sat, 19 May 2001, Linus Torvalds wrote: > > On Sat, 19 May 2001, Pavel Machek wrote: > > > > Well, if we did something like modify(int fd, char *how), you could do > > > > modify(0, "nonblock,9600") > > What you're really proposing is to make ioctl's be ASCII strings. > > Which is not necessarily a bad idea, and I think plan9 did something > similar (or rather, if I remember correctly, plan9 has control streams > that were ASCII. Or am I confused?). You are not. Control streams in question look like normal files. Normally driver exports a tree with several data files (e.g. fd0, fd1, fd2, fd3) and several control files (e.g. fd0ctl, fd1ctl, fd2ctl, fd3ctl). write() to the latter passes commands. No extra syscalls needed. Notice that sometimes it's not ASCII - depends on the nature of stuff you are passing. Things like setting font, etc. need to pass bitmaps, so some parts of the stuff you write end up as binary. Which is perfectly sane. > And a "stream of bytes" is in a very real sense the simplest structure, > and is the unix way (and the plan9 way is to avoid binary streams, and use > ASCII text instead when possible, whihc probably also makes sense). s/possible/makes sense/. For commands ASCII is OK, but for cases when you pass binary data as a part of command (not just "something large", but something that really happens to be a bitmap, etc.) you write it as binary data. - 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
Linus Torvalds wrote:
>
> [ Attribution is gone, so I just deleted it.. ]
>
> > > > > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > > >
> > > > Hmm, there might be problem with this. How do you change speed without
> > > > reopening device? [Remember: your mice knows when you close device]
>
> The naming scheme is not a replacement for these kinds of ioctl's - it's
> just a way to make them less critical, and get people thinking in other
> directions so that we don't get _more_ ioctl's.
However
fchdir(fd);
s = open("speed");
write(s, "19200\n", 6);
would be enough to solve the problem Pavel is pointing also without the
need to use ioctl.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
-
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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
On Sat, 19 May 2001, Pavel Machek wrote: > > Well, if we did something like modify(int fd, char *how), you could do > > modify(0, "nonblock,9600") What you're really proposing is to make ioctl's be ASCII strings. Which is not necessarily a bad idea, and I think plan9 did something similar (or rather, if I remember correctly, plan9 has control streams that were ASCII. Or am I confused?). > I thought about how to do networking without sockets, and it seems to > me like this kind of modify syscall is needed, because network sockets > connect to *two* different places (one local address and one > remote). Sockets are really nasty :-(. One of the horrors of ioctl's is indeed that they are not very well-defined, and as such cannot be transported over a network without knowing more about them. Structuring them some way would already be very useful. the _IOC() macros do this partially, of course, but because it is a voluntary thing it is not actually followed all that well in general, and most ioctl names are just random numbers that don't tell the structure of the arguments or return values. And a "stream of bytes" is in a very real sense the simplest structure, and is the unix way (and the plan9 way is to avoid binary streams, and use ASCII text instead when possible, whihc probably also makes sense). However, you can't really use a string. It would really have to be two memory regions: incoming and outgoing, with an ASCII representation being the _preferred_ method for stuff that isn't obviously structured or performance-critical. Let's not take this too far, though. 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: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumber Registrants]
[ Attribution is gone, so I just deleted it.. ]
> > > > fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
> > >
> > > Hmm, there might be problem with this. How do you change speed without
> > > reopening device? [Remember: your mice knows when you close device]
The naming scheme is not a replacement for these kinds of ioctl's - it's
just a way to make them less critical, and get people thinking in other
directions so that we don't get _more_ ioctl's.
Remember, the serial lines we already have legacy support for, that's not
going away. The termios-based stuff isn't Linux-only, and we'll
obviously maintain it for the forseeable future.
But if we can use naming to avoid ioctl's in the future, then THAT is
good. I'm in particular thinking about frame-buffer and similar things,
where we might be able to avoid making the situation worse.
And remember where this discussion started: not ioctl's, but device
numbers. The _biggest_ advantage of naming may be to get rid of the need
for extra major and minor numbers, and cleaning up /dev in the process-
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/
