Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum

Oliver Xymoron
2001-05-21T18:36:36Z

On Mon, 21 May 2001, Alexander Viro wrote:

> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > If you've got side channels that are of a packet nature (aka commands),
> > then they can all happily coexist on one device. If you've got channels
> > that are streams or intended for mmap, those ought to be different
> > devices.
>
> Since you've been refering to -9 - care to take a look at the contents of
> uart(3)? Or lpt(3). Or draw(3), for that matter.

K - so what? I'm guessing what you want me to see is that these
implement multiple channels. Is there a reason that eia001stat couldn't be
implemented as

f=open("/dev/eia001ctl",O_RDWR);
write(f,"stat\n");
status=read(f); /* returns "stat foo\n" */

We don't want to implement a separate device node for every OOB ioctl that
returns data, do we? Why should stat be any different?

/dev/draw is interesting but largely irrelevant. And again, colormap and
refresh - why are they not part of ctl? You've got to select on refresh
anyway, might as well accept asynchronous messages through ctl.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."