patchlevel 6
Linus Torvalds
track my kernel versions, the weekly patch is available at nic.funet.fi,
pub/OS/Linux/testing/Linus.
This patch does not contain any major bug-fixes: it corrects named pipes
that broke with pl5, and has some minor changes in the IO-instructions
and the hd-driver, but those shouldn't matter for most of you.
It does contain all the scsi-patches that I've gotten so far, so if the
bootup sequence died on you in the scsi code, pl6 should correct this.
The major part of the patch is tytso's serial line changes, making the
tty structures dynamic. No more NR_PTY's - the number of pty's is now
bounded only by the minor number setup (max 64 pty's) or the amount of
memory available (opening a pty requires a page of memory for tty
queues). Similarly for serial lines.
The above just means that while pl6 can be useful, the changes to pl5
aren't big enough to worry about. Most people don't use named pipes, it
seems, and the other changes are either cosmetic or hardware-dependent.
I still hope people upgrade, if only so that I can get new bug-reports.
I had hoped to release 0.98 this weekend, but studies and the scsi/hd
problems put an end to that. 0.98 should be out next weekend or so.
Expect the tcp/ip subdirectory and possibly some mm changes.
Linus
Linus Torvalds
>You all know what the subject line means by now: in case you want to
>track my kernel versions, the weekly patch is available at nic.funet.fi,
>pub/OS/Linux/testing/Linus.
Arggh. While the full source was ok, the patch was generated with
"+ignore-all-spaces" in the hope that it would be smaller that way. And
yes, the patch is smaller, but it doesn't actually work :-( The full
source to pl6 is ok, but if you got only the patch, you'll get errors
when applying it. I'll put a corrected patch at nic at once.
Linus
H. Peter Anvin N9ITP
torv...@klaava.Helsinki.FI (Linus Torvalds) writes:
>
> The major part of the patch is tytso's serial line changes, making the
> tty structures dynamic. No more NR_PTY's - the number of pty's is now
> bounded only by the minor number setup (max 64 pty's) or the amount of
> memory available (opening a pty requires a page of memory for tty
> queues). Similarly for serial lines.
>
Actually, the way things are it is limited by the /dev/tty* naming
conventions, which unwisely introduced a namespace conflicts between serial
lines and pty slaves. Thus there is now an artificial limit of 49 ptys. I
would personally like to see the BSD naming convention used, which would
resolve this naming conflict while only change the names of serial lines,
is an established convention and which would not interfere with any known
software.
The convention is:
/dev/tty[a-z] : Serial lines
/dev/tty[p-z][0-9a-f] : PTY slaves
/dev/pty[p-z][0-9a-f] : PTY masters
/dev/tty[1-8] : (by extension) VTcons.
This convention would eliminate the ambiguity currently existing for
/dev/ttys? while remaining largely compatible.
/hpa
--
INTERNET: h...@nwu.edu TALK: h...@casbah.acns.nwu.edu
BITNET: HPA@NUACC IBMNET: 16331@IBMX400
HAM RADIO: N9ITP NeXTMAIL: h...@lenny.acns.nwu.edu
"Kissing a smoker is like licking an ashtray." -- R. Heinlein
Russell Nelson
/dev/tty[a-z] : Serial lines
/dev/tty[p-z][0-9a-f] : PTY slaves
/dev/pty[p-z][0-9a-f] : PTY masters
/dev/tty[1-8] : (by extension) VTcons.
It's not up for a vote (Linus is a benevolent dictator), but I agree...
-russ <nel...@crynwr.com> I'm proud to be a humble Quaker!
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice
Potsdam, NY 13676 315-268-9201 FAX
Peter Eriksson
>In article <1992Sep21....@news.acns.nwu.edu> h...@nwu.edu writes:
> /dev/tty[a-z] : Serial lines
> /dev/tty[p-z][0-9a-f] : PTY slaves
> /dev/pty[p-z][0-9a-f] : PTY masters
> /dev/tty[1-8] : (by extension) VTcons.
>It's not up for a vote (Linus is a benevolent dictator), but I agree...
Me too! Me too! :-)
--
Peter Eriksson p...@lysator.liu.se
Lysator Academic Computer Society ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden I'm bored. Flame me.
Theodore Ts'o
|
| /dev/tty[a-z] : Serial lines
| /dev/tty[p-z][0-9a-f] : PTY slaves
| /dev/pty[p-z][0-9a-f] : PTY masters
| /dev/tty[1-8] : (by extension) VTcons.
|
|It's not up for a vote (Linus is a benevolent dictator), but I
|agree...
Actually, it's more up to the people putting out the root disk and the
various releases (MCC, SLS, etc.).
It's not clear to me that a Linux system would ever need more than 49
pty's, so I'm not so sure that moving /dev/ttysXX is such a pressing
need. The concern I have with using /dev/tty[a-z] is that it only gives
you 26 serial lines, and with 0.97pl6, we're up to /dev/ttys13 already.
And that doesn't include the HUB-6 card that people have asked me to
support (but for which I don't have detailed specs for yet), which would
be another 6 minor numbers assigned.
If people really want more than 49 PTY's (and I really don't see why you
ever would need that many), then how about moving /dev/ttysXX to
/dev/ttySXX? That's a solution that's been done before, too. Actually,
what might be the best thing is to make /dev/ttySXX be a one-to-one map
with the minor numbers, and allow the user to make symlinks as he/she
chooses; so one such person have the following symlinks on their system:
/dev/ttyS0 ---> /dev/ttya
/dev/ttyS1 ---> /dev/ttyb
/dev/ttyS12 ---> /dev/ttyc
/dev/ttyS13 ---> /dev/ttyd
Since these symlinks would differ from system to system, the user would
have to set them up on his own, though.
- Ted
Michael A. Irons
In responce to Teds posting, there should be on consistant naming
convention of all the different packages. Could you imagine having different
tty names, and the newbie questions that would flood the net!! As for that many
pttys, with the coming of TCP/IP and X they both use pttys, and there should be
as little constraint as possible. Personally Ted's suggestion of using ttyS??
instead of ttys?? seems to be the best/least intrusive choice. Most importantly
is that everyone (especially people putting out initial setup kits) use the
same conventions. Also people compiling binaries use that same convention.
(One nasty example is that the xc binary I can't use because kermit & uucp
use spool/locks, not spool/uucp like xc {causes havoc when uucp calls out not
seeing xc's LCK files, fun for newbies} ).
Mike Irons
--
--
Mike Irons;
mir...@Dworkin.CCS.Northeastern.EDU (School)
mirons%minix...@MecEng.COE.Northeastern.EDU (Home)
Ian Jackson
> /dev/tty[a-z] : Serial lines
> /dev/tty[p-z][0-9a-f] : PTY slaves
> /dev/pty[p-z][0-9a-f] : PTY masters
> /dev/tty[1-8] : (by extension) VTcons.
I agree with the suggestion above. However ...
In comp.os.linux ty...@ATHENA.MIT.EDU (Theodore Ts'o) writes:
>It's not clear to me that a Linux system would ever need more than 49
>pty's, [...]
When running X windows you may well do. It seems more likely than
having more than 26 serial lines.
>The concern I have with using /dev/tty[a-z] is that it only gives you
>26 serial lines, and with 0.97pl6, we're up to /dev/ttys13 already. [...]
How about using /dev/tty[a-f][a-z] after you've used up all the
tty[a-z]. That will look reasonably consistent (only another `digit'
after all) and give you more names than you could possibly need.
The question is really, do we want to make the namespace uglier for
more than 49 pty's or for more than 26 tty's, and how much uglier in
each case ? I think this proposal makes the default namespace a little
nicer, improves the case with >49 pty's greatly, and doesn't do much
damage to >26 ttys.
>[ttySXX and symlink suggestion deleted to save space]
I'm sorry, but I really think symlinks ought to be kept out of /dev as
much as possible. Whole banks of them would be a real mess; also that
would give two places for things to go wrong with new users' systems.
--
Ian Jackson The opinions expressed here are my own.
i...@cam-orl.co.uk / ...!mcsun!uknet!cam-orl!iwj
Theodore Ts'o
Date: 24 Sep 92 15:21:03 GMT
In comp.os.linux ty...@ATHENA.MIT.EDU (Theodore Ts'o) writes:
>It's not clear to me that a Linux system would ever need more than 49
>pty's, [...]
When running X windows you may well do. It seems more likely than
having more than 26 serial lines.
I use X11 extensively (I'm at MIT, after all, where Motif was
originated, although we tend to be ashamed of that fact :-), and I have
yet to exceed 16 pty's, let alone 49. Think about what uses pty's:
xterms, Emacs shell-buffers, and script commands. Are you really going
to have that many of those programs running at the same time?
It is very likely that the serial driver will eventually have support
for more than 26 serial lines; the issue is that different people will
have different combinations of serial boards. For example, someone
with an Accent serial card will have the following minor devices
available to them: minor devices 64, 65, 76, and 77, corresponding to
devices /dev/ttys0, /dev/ttys1, /dev/ttys12, and /dev/ttys13. Someone
with an AST fourport plus a normail serial board might have the
following minor devices: 64, 65, 68, 69, 70, 72, corresponding to
/dev/ttys[0-1], and /dev/ttys[4-7]. So it is quite likely that the
namespace of /dev/tty[a-z] would be exhausted, additional boards are
supported.
How about using /dev/tty[a-f][a-z] after you've used up all the
tty[a-z]. That will look reasonably consistent (only another `digit'
after all) and give you more names than you could possibly need.
Ick. Ugly. I much prefer /dev/ttyS0 ... /dev/ttyS63; much more
understandable. (If it were up to me, I would have used /dev/ttyp0 ...
/dev/ttyp63, as being eminently more logical, but BSD didn't chose this
convention. Sigh....)
>[ttySXX and symlink suggestion deleted to save space]
I'm sorry, but I really think symlinks ought to be kept out of /dev as
much as possible. Whole banks of them would be a real mess; also that
would give two places for things to go wrong with new users' systems.
No, there wouldn't be a whole bank of symlinks. If a user has four
serial ports on their system, there would be four symlinks; no more.
If you don't do the symlinks, users will get confused about whether they
should be using /dev/ttys4 or /dev/ttys12 to get to the third serial
port on their system. Once things are set up they will *know* that
/dev/ttyc will get them the third serial port.
The only other solution would be automatically renumber the minor device
numbers on boot up, depending on what serial boards you have plugged in.
However, this is BAD, since it means that confusing things happen when
you plug in a new serial board --- all of a sudden, which device
/dev/ttys3 goes to would change without warning. At least with
symlinks, the user has to modify them by him or herself.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o bloom-beacon!mit-athena!tytso
308 High St., Medford, MA 02155 ty...@athena.mit.edu
Everybody's playing the game, but nobody's rules are the same!
Ian Jackson
I use X11 extensively [...] and I have
yet to exceed 16 pty's, let alone 49. [...] Are you really going
to have that many [pty's used] at the same time?
I've had 20 sometimes. You only need two or three users (even idle
ones) and then you'll run out. Apart from which the namespace clash is
inelegant, and confusing if you have all the available pty's mknodded.
[minor numbers = ttys numbers, support for many serial boards,
deleted to save space]
If you don't do the symlinks, users will get confused about whether they
should be using /dev/ttys4 or /dev/ttys12 to get to the third serial
port on their system. Once things are set up they will *know* that
/dev/ttyc will get them the third serial port.
I didn't mean for each tty[a-z] to be a particular unique minor
number. tty[a-z] would refer to the actual physical ports on a
particular machine, and would have different minor numbers on machines
with different serial boards. You seem to agree with me here. The
question then is whether there should be another set of names for each
minor number, and if so what should those names be and should the
tty[a-z] be symlinks ?
Personally I don't think another set of names is necessary or
desirable. The only thing you gain by having them is ordinary user
level access to the full range of minor numbers; root can just create
a new device when sie needs one. If you do decide to have them they're
only going to be there for installation etc. anyway (ie you won't use
them most of the time), so you can call them ttySnn (as you suggest
later on).
As to the question of symlinks if you do have the ttySnn names,
tty[a-z] IMHO should be device files in their own right. This will
mean that naive users won't see the links and try to use the ttyS
names and get confused. The standard distribution would come with
tty[a-z] set up as the standard serial drivers. Name -> number mapping
is already done in /dev with special files - why use symlinks ?
[renumbering devices at boot-time, deleted to save space]
I agree, that would be awful.
Summary:
I think the user wouldn't find it more difficult to re-mknod the
`user-level' names (tty[a-z]) with different numbers than to relink
symlinks, and this avoids people using the `fixed-minor-number' ttySnn
devices when they ought to use the normal ones. If you really need all
the minor numbers available in /dev then ttySnn is preferable to
ttysnn, because it emphasises that there is something odd about them
(ie most of them won't refer to any actual hardware, and they
shouldn't be used in most circumstances) and it doesn't clash (so
soon) with the pty namespace.
--
Ian Jackson i...@cam-orl.co.uk / ...!uknet!cam-orl!iwj +44 223 343398, 327029
Opinions expressed here are my own. 35 Molewood Close, Cambridge, CB4 3SR, UK
Johan Wåhlin
>In article <1992Sep21....@news.acns.nwu.edu> h...@nwu.edu writes:
>|
>| /dev/tty[a-z] : Serial lines
>| /dev/tty[p-z][0-9a-f] : PTY slaves
>| /dev/pty[p-z][0-9a-f] : PTY masters
>| /dev/tty[1-8] : (by extension) VTcons.
>|
>It's not clear to me that a Linux system would ever need more than 49
... deleted lines
>ever would need that many), then how about moving /dev/ttysXX to
>/dev/ttySXX? That's a solution that's been done before, too. Actually,
I like /dev/ttySxx
... deleted lines
> - Ted
/Johan
--
/Johan W}hlin (.. where the } really is an a with a ring above it.. 8))