>
>
> On Sun, 4 Jan 1998, Richard Gooch wrote:
> > Linus Torvalds writes:
> >
> > > Btw, devfs should probably think long and hard about pty's...
> >
> > I don't know what you had in mind here. There is the issue of
> > registering all these /dev entries, but it should be easy enough to
> > come up with an interface which doesn't require a driver to call
> > dev_register() a zillion times (i.e. code in devfs effectively does
> > the individual registrations).
>
> What I was thinking about was to maybe skip the notion that all pty's are
> available in /dev at all, and take the plunge to a real "open_pty()"
> functionality (I don't remember the name of the interface that allocates a
> new master pty - but we can certainly avoid the horror of walking through
> all pty's one at a time until we find a non-busy one). Our current
> pty-opening strategy is the original (fairly broken) BSD one, and just
> about everybody else has moved on to another way of finding a pty to open.
>
> Having zillions of pty's in devfs is not something I'd like to see.
Agreed. Some OSes handle this sort of thing using "clonable" devices.
For example, if you want a network communication endpoint (i.e. a socket),
you open NET0:. The handle you get back, however, is for e.g. NET327:
which was created by the open call. When the use count for the object
goes to zero, the object is deleted. NET0: is created by the driver when
it is loaded, and new instances of the object type pick up access mask,
etc. from the "template" instance, which can be configured by startup
scripts if need be (though the driver provides some reasonable default).
(Of course the owner of the instance is not copied from the template.)
On the system I'm thinking of, the numbers increase monotonically with
wrapping. That means it's unlikely that the name objN: would be recycled
quickly enough to confuse things that still think they know what it
means.
Properties of this approach:
o You can check for the presence of the driver by checking for the
existence of the template.
o You always know which name to open without searching.
o You never run out of objects so long as the kernel can find memory
to represent them. (On Unix-like systems you may run out of
major/minor namespace to distinguish them, but that's being
worked on.)
o Only objects actually in use (plus the template) are present in
the namespace.
o It's simple to set initial permissions, etc. for a class.
o The driver handles the population of the namespace -- no daemons,
and no scripts unless you want them.
In the pty case, naturally the driver would have to create/destroy the
objects in pairs. Since the members of each pair will most likely be
used by different processes, this poses some interesting problems, but I
think that they aren't insurmountable and a good deal of the work may
already have been done.
(How's that for "I haven't actually looked at it but it ought to work"? :-)
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Legacy system: installed before the speaker arrived; therefore outdated, despised, to be replaced ASAP.