Re: [PATCH] 2.5.17 /dev/port

Re: [PATCH] 2.5.17 /dev/port

[Andries.Brouwer]

> Anybody: if you've ever used /dev/ports, holler _now_.

Holler.


In my eyes /dev/port is a rather unimportant corner
of the kernel. Removing it does not streamline anything,
we hear that it saves 454 bytes. A worthy goal, but..

Today a few things use /dev/port. Some low level mouse,
keyboard and console utilities. kbdrate. hwclock.

Is it needed? Hardly - most uses can be replaced by inb()
and outb(). But I am not sure why that would be better.
And I seem to recall that hwclock on some flavours of Alpha
really needed the /dev/port way. But I may be mistaken.


I have also seen systems that used /dev/port as
the implementation of inb() and and outb():
 outb(int p, char v) { lseek(fd,p,0); write(fd,&v,1); }
That way one could access keyboard, sound, rtc etc
while the underlying hardware was rather different from i86.


A further advantage of having /dev/port is that it allows one
to set keyboard or mouse or whatever properties from anything
that is able to access a file. But outb() or ioctl() probably
require something close to a C environment.
Probably this is what Alan is saying.


It is rather unimportant, but there are a few uses, and removing it
does not really have any positive effect. Quickly the 454 bytes
won will be lost again to the new ioctls, and to the filesystem
that Al develops to set the border colour of the monitor screen
and become a bleeding edge developer too.


Andries

Re: [PATCH] 2.5.17 /dev/port

[H. Peter Anvin]

Followup to:  <UTC200205222246.g4MMkNL26024.aeb@smtp.cwi.nl>
By author:    Andries.Brouwer@cwi.nl
In newsgroup: linux.dev.kernel
> 
> In my eyes /dev/port is a rather unimportant corner
> of the kernel. Removing it does not streamline anything,
> we hear that it saves 454 bytes. A worthy goal, but..
> 
> Today a few things use /dev/port. Some low level mouse,
> keyboard and console utilities. kbdrate. hwclock.
> 
> Is it needed? Hardly - most uses can be replaced by inb()
> and outb(). But I am not sure why that would be better.
> And I seem to recall that hwclock on some flavours of Alpha
> really needed the /dev/port way. But I may be mistaken.
> 

On non-Intel platforms, with no dedicated IOIO opcodes, IOIO is
usually implemented as a specific memory range.  In that case, the
only way to allow user-space access to it would be to mmap() that
range... which means iopl() inb() and outb() on those platforms might
be implemented either as open, readp and writep, respectively, or by
iopl() being open() followed by mmap().

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [PATCH] 2.5.17 /dev/port

[Alan Cox]

> On non-Intel platforms, with no dedicated IOIO opcodes, IOIO is
> usually implemented as a specific memory range.  In that case, the
> only way to allow user-space access to it would be to mmap() that
> range... which means iopl() inb() and outb() on those platforms might
> be implemented either as open, readp and writep, respectively, or by
> iopl() being open() followed by mmap().

mmap and some other logic in certain cases. An outb stalls until the I/O
hits the device even on PCI.  Either way thats really about what you
put into /dev/port (either the i/o logic or a map of /dev/mem with slightly
tweaked args)