Re: [PATCH] 2.5.17 /dev/ports

Re: [PATCH] 2.5.17 /dev/ports

[Pete Zaitcev]

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

I often use it as an alternative to #include <asm/io.h>,
which you decreed illegal. I understand <sys/io.h> is a legal
alternative, but a bunch of platforms forget to
include <sys/io.h>, for instance Jes cried bloody murder
when asked to add it to ia-64. But if you decide to drop /dev/port
I can tough it out. Solaris lives without it, and so can we.

I saw this whining about outl not implemented for
write(fd, &my_int, 4), and I think the guy had a little point.
Though if he wanted it, he ought to submit a patch.

-- Pete

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Użytkownik Pete Zaitcev napisał:
>>Anybody: if you've ever used /dev/ports, holler _now_.
>>
>>		Linus
> 
> 
> I often use it as an alternative to #include <asm/io.h>,
> which you decreed illegal. I understand <sys/io.h> is a legal
> alternative, but a bunch of platforms forget to
> include <sys/io.h>, for instance Jes cried bloody murder
> when asked to add it to ia-64. But if you decide to drop /dev/port
> I can tough it out. Solaris lives without it, and so can we.
> 
> I saw this whining about outl not implemented for
> write(fd, &my_int, 4), and I think the guy had a little point.
> Though if he wanted it, he ought to submit a patch.


Hey and finally if someone want's to use /dev/port for
developement on some slow control experimental hardware for example.
Why doesn't he just delete the - signs at the front lines
of the patch deleting it plus module register/unregister trivia and
compile it as a *separate* character device module ?
That's linux - you have the source, so use it.
You wan't to cheat around the OS abstractions - do it for yourself!
There is no requirement that it has to be
permanently in the mainline kernel where it tends to
attract people who shouldn't have used it in first place
for generic stuff like kbd rate settings and clock device
manipulation.

Re: [PATCH] 2.5.17 /dev/ports

[Linus Torvalds]

On Thu, 23 May 2002, Martin Dalecki wrote:
> 
> Hey and finally if someone want's to use /dev/port for
> developement on some slow control experimental hardware for example.
> Why doesn't he just delete the - signs at the front lines
> of the patch deleting it plus module register/unregister trivia and
> compile it as a *separate* character device module ?

That's not a productive approach, Martin.

Yes, with open source you can do whatever you want.

HOWEVER, there is a huge amount of advantage to having a common base that 
is big enough to matter: why do you think MS does well commercially? 

It's important to _not_ have to force people to do site-specific (or 
problem-specific) hacks, even if they could do so. Because having to have 
site-specific hacks detracts from the general usability of the code.

So when simplifying, it's not just important to say "we could do without 
this". You have to also say "and nobody can reasonably expect to need it".

Which doesn't seem to be the case with /dev/ports. So it stays.

		Linus

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Linus Torvalds napisa?:
> On Thu, 23 May 2002, Martin Dalecki wrote:
> 
>>Hey and finally if someone want's to use /dev/port for
>>developement on some slow control experimental hardware for example.
>>Why doesn't he just delete the - signs at the front lines
>>of the patch deleting it plus module register/unregister trivia and
>>compile it as a *separate* character device module ?
> 
> 
> That's not a productive approach, Martin.

"I will submitt my dual 8255 PIO ISA card driver from 1.xx days
immediately for kernel inclusion"

This was the exmaple I had in my mind as I wrote the above.
Slow controll means in experimental physics - controll of
devices which don't have hard real time constrains.
Once in my life I wrote a driver for such a beast which was
controlling an experimental tomography device. But I have
found it specific and trivial enough to don't bother to
submitt it to the general public. It was *trivial* to
implement becouse I could trick the LP driver to do what
I wanted by deleting most of the code in it.
I assume that this kind of application is what Pete was
talking about as he was speaking about "quite frequently"
and finally "Solaris does without it so we could as well".

This was what I had in my mind with the advantage of having
full access to the source code of the system. I certainly
don't buy myself in the philosophical zealots view of
of open source OS supreriority quite frequently propagated here
by some individuals.

And please note even at the time then I didn't write
the application by using the cards from user land
directly - I just wrote the damn driver for it, becouse
the "cheating" smelled to me immediately.

> Yes, with open source you can do whatever you want.
> 
> HOWEVER, there is a huge amount of advantage to having a common base that 
> is big enough to matter: why do you think MS does well commercially? 
> 
> It's important to _not_ have to force people to do site-specific (or 
> problem-specific) hacks, even if they could do so. Because having to have 
> site-specific hacks detracts from the general usability of the code.
> 
> So when simplifying, it's not just important to say "we could do without 
> this". You have to also say "and nobody can reasonably expect to need it".

What I'm saying is: It has already caused people who write applications
to control things like the system clock settings or keyboard speed
to write the applications in a way which:

1. doesn't use the proper system interfaces,
2. is attracted to the particular hardware implementation
3. is inherently not portable across different systems. (Alan got this wrong).
4. a damn comon thing to do.

As a consequence of this it has caused the system
interfaces for those purposes to never mature.
USB keyboards to name one.

The single only guy who wanted to use it for some sane purpose
and  had some serious intentions about it noticed immediately
that it is BTW seriously broken from day one on!

So in regard of the above I have decided for myself that
the sanest way to fix it is to remove it.

> Which doesn't seem to be the case with /dev/ports. So it stays.
> 
> 		Linus

I think one doesn't have only to provide things. One has
to prevent damage as well. And hwclock and kbdrate are
seriously damaged already for example. Once just didn't
notice until now becouse it all kind of "works".
Please look at the code there.

If you reffer to MS as a success story of about how to
be a bitch to everybody ... well please tell me: Why do we use
page protection for example at all. The implementers of
DOS where not even dreaming about it and Win98 didn't care.
All of the follow up operating systems from Redmond are
making it seriously difficult to get direct hardware access.
For scincetific applicatons there are even some special third
party expensive drivers out there which are supposed to
permitt just that - port access from user space.

This is one of the reasons I did implement the host controll
software for the tomography device under Linux and NOT any
windows or doors system. And it was in fact the first Linux
in experimental medicine around there! (The circle was quite
wide those days...)

Re: [PATCH] 2.5.17 /dev/ports

[Christer Weinigel]

Martin Dalecki <dalecki@evision-ventures.com> wrote:

> "I will submitt my dual 8255 PIO ISA card driver from 1.xx days
> immediately for kernel inclusion"

Please do *grin* I will probably have to write a driver for just such
a card (a PC104 card though, but that's just a differenct connector),
so I'd love to have such a driver.  And as long as the driver is
self-contained and doesn't mess with other parts of the kernel I can't
see why it shouldn't be included in Linus' tree.  The same is IMHO
true about /dev/port, it's rather self-contained and is less than 50
source lines in mem.c.  It may be ugly but it's useful for some people.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: [PATCH] 2.5.17 /dev/ports

[Pete Zaitcev]

> From: Christer Weinigel <wingel@acolyte.hack.org>
> Date: Thu, 23 May 2002 23:22:39 +0200 (CEST)

> Martin Dalecki <dalecki@evision-ventures.com> wrote:
> 
> > "I will submitt my dual 8255 PIO ISA card driver from 1.xx days
> > immediately for kernel inclusion"
> 
> Please do *grin* I will probably have to write a driver for just such
> a card (a PC104 card though, but that's just a differenct connector),
> so I'd love to have such a driver. [...]

The 8255 is way too flexible for a single driver to be possible,
IMHO. Also, it is used in devices which plug into a variety of
upstream APIs, which makes the factorization not worth the effort.
E.g. what if you have 8255 driving a 9 track tape and 8255 driving
HP-IB bus? I think it would hardly be reasonable to unify those.
OTOH, If Martin submits a header file with register breakdown,
it may be useful (unlike a continuation of /dev/port discussion).

-- Pete

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Pete Zaitcev napisa?:
>>From: Christer Weinigel <wingel@acolyte.hack.org>
>>Date: Thu, 23 May 2002 23:22:39 +0200 (CEST)
> 
> 
>>Martin Dalecki <dalecki@evision-ventures.com> wrote:
>>
>>
>>>"I will submitt my dual 8255 PIO ISA card driver from 1.xx days
>>>immediately for kernel inclusion"
>>
>>Please do *grin* I will probably have to write a driver for just such
>>a card (a PC104 card though, but that's just a differenct connector),
>>so I'd love to have such a driver. [...]
> 
> 
> The 8255 is way too flexible for a single driver to be possible,
> IMHO. Also, it is used in devices which plug into a variety of
> upstream APIs, which makes the factorization not worth the effort.
> E.g. what if you have 8255 driving a 9 track tape and 8255 driving
> HP-IB bus? I think it would hardly be reasonable to unify those.
> OTOH, If Martin submits a header file with register breakdown,
> it may be useful (unlike a continuation of /dev/port discussion).


Well I wasn't serious about this submission thing precisely
for the above reasons. From long past times I can remember
that those beasts could be configured to have A B C D or whichever
ports, which could be neraly infinitely permuted to provide
many not usefull combinations of 4 or 8 bit bus buffers.
The externall visible register address or data lines where very
likely to be permutted between the chip and the data part of the ISA bus,
just becouse the layouter of the card did feel like beeing creative.
(So even register values won't help you!)
And last but not least they could be coupled in bunches.
So the chances for a genrically usefull driver are indeed not big.

And last but not least: The source for a driver for a 1.0.xx kernel
isn't very usefull nowadays.
And admittedly, well most lekely I don't have the code around
any longer... but it was just about 400 lines I can remember.

Re: [PATCH] 2.5.17 /dev/ports

[Robert Schwebel]

On Thu, May 23, 2002 at 11:22:39PM +0200, Christer Weinigel wrote:
> Please do *grin* I will probably have to write a driver for just such
> a card (a PC104 card though, but that's just a differenct connector),
> so I'd love to have such a driver.  And as long as the driver is
> self-contained and doesn't mess with other parts of the kernel I can't
> see why it shouldn't be included in Linus' tree.

COMEDI is the way to go for things like these. So if you want to make a
driver for your device you should subscribe the comedi mailing list first
and look if anybody has already done the work for you. 

Robert
-- 
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH] 2.5.17 /dev/ports

[Pete Zaitcev]

> Date: Thu, 23 May 2002 21:31:23 +0200
> From: Martin Dalecki <dalecki@evision-ventures.com>

> Slow controll means in experimental physics - controll of
> devices which don't have hard real time constrains.
>[...]
> I assume that this kind of application is what Pete was
> talking about as he was speaking about "quite frequently"
> and finally "Solaris does without it so we could as well".

I used it for I2C on VGA cards and different ISA devices,
and flash programming. Remember that though ISA went away on
desktop, embedded people still use it. It was just FYI - if you
persuade Linus to strike /dev/port down, I am not going to shed
many tears, only a little :)  It may be different for users
of languages other than C, but let them defend themselves.

-- Pete

Re: [PATCH] 2.5.17 /dev/ports

[James Simmons]

>On Wed, May 22, 2002 at 03:58:38PM +0100, Alan Cox wrote:
> > > > IOCTL is ineed the way to go to implement such functionality...
> > >
> > > Yes, the EVIOCSREP ioctl will be the one soon (works for USB
> > > keyboards now).
> >
> > The KBDRATE ioctl is already supported by all other keyboard drivers
> > and used by XFree86....
>
>Correct. And it'll work on USB as well once the console code is
>interfaced to USB better than just by injecting scancodes into
>pc_keyb.c.
>
>KBDRATE will work on console, while EVIOCSREP will work if you open the
>keyboard as an event device.

Alan you are thinking to PC here. On embedded devices that run X it is
just extra over head to use the VT interface. It would be much lighter
weigth to use the /dev/input/event interface. Personally I like to see
KBDRATE and alot of other junk go away in the console code. Intead we
just use the input api and /dev/fb with DRI. I have talked to Jim Getty
about this and likes to see things head in this direction.

P.S
   Jim Getty was working on having X windows using the input api :-) 
   

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> Alan you are thinking to PC here. On embedded devices that run X it is
> just extra over head to use the VT interface. It would be much lighter
> weigth to use the /dev/input/event interface. Personally I like to see
> KBDRATE and alot of other junk go away in the console code. Intead we
> just use the input api and /dev/fb with DRI. I have talked to Jim Getty
> about this and likes to see things head in this direction.

DRI ? What good is DRI to me on an embedded box. What good is an fb driver
when my hardware does text mode ? Why do I want the whole input layer loaded
for a single fixed keyboard controller, or a serial interface driven by user
mode ?

Re: [PATCH] 2.5.17 /dev/ports

[James Simmons]

> > Alan you are thinking to PC here. On embedded devices that run X it is
> > just extra over head to use the VT interface. It would be much lighter
> > weigth to use the /dev/input/event interface. Personally I like to see
> > KBDRATE and alot of other junk go away in the console code. Intead we
> > just use the input api and /dev/fb with DRI. I have talked to Jim Getty
> > about this and likes to see things head in this direction.
> 
> DRI ? What good is DRI to me on an embedded box. 

You be surprised what is coming out soon into the embedded market :-) 3D
will soon be coming to small hand held devices!!

> What good is an fb driver when my hardware does text mode ? 

Text mode is the expection not the norm. 

> Why do I want the whole input layer loaded for a single fixed keyboard
> controller, or a serial interface driven by user mode ?

One is portablity. The input layer handles more than just keyboards.
All input devices look the same. Most embedded devices with input
interfaces have more than one type of input device (touchscreen,
attachable keyboards, buttons etc). Plus the input layer is modular and it
is small. 

Linux-2.5.17

[Linus Torvalds]

Various FS updates (including merges of quota and iget_locked), and
Makefile cleanups from Kai.

And yet more TLB shootdown stuff.

		Linus

-----

Summary of changes from v2.5.16 to v2.5.17
============================================

<acme@conectiva.com.br>
	copy_from/to_user checking in
	 o drivers/sound/*.c
	 o fs/intermezzo/ext_attr.c
	 o drivers/isdn/*.c
	 o drivers/usr/*.c
	 o sound/{core,pci}/*.c
	 o drivers/char/*
	 o drivers/block/*.c

Andrew Morton <akpm@zip.com.au>
	o check for dirtying of non-uptodate buffers
	o reduce lock contention in do_pagecache_readahead
	o larger b_size, and misc fixlets
	o fix dirty page management
	o reiserfs locking fix
	o pdflush exclusion infrastructure
	o dirty inode management
	o i_dirty_buffers locking fix
	o ext2: preread inode backing blocks
	o pdflush exclusion
	o fix ext3 race with writeback
	o fix ext3 buffer-stealing
	o writeback tuning
	o remove PG_launder
	o improved I/O scheduling for indirect blocks

<david@gibson.dropbear.id.au>
	o Missing init.h in drivers/pci/power.c

<dmccr@us.ibm.com>
	o Thread group exit problem reappeared

Christoph Hellwig <hch@infradead.org>
	o cleanup read/write
	o Small cleanup of nfsd export checks
	o kNFSd cleanup of nfsd_open
	o get rid of <linux/locks.h>

<jack@suse.cz>
	o quota-1-newlocks
	o quota-2-formats
	o quota-3-register
	o quota-4-getstats
	o quota-5-space
	o quota-6-bytes
	o quota-7-quotactl
	o quota-8-format1
	o quota-9-format2
	o quota-10-inttype
	o quota-11-sync
	o quota-12-compat
	o quota-13-ioctl

<jaharkes@cs.cmu.edu>
	o iget_locked  [1-6]

<jhammer@us.ibm.com>
	o ips for 2.5

<kai@tp1.ruhr-uni-bochum.de>
	o Rules.make cleanup: introduce c_flags, a_flags
	o Remuve some cruft from top-level Makefile
	o Move DocBook stuff out of top-level Makefile
	o Move arch specific options to their Makefile
	o Don't implicitly export all symbols
	o top-level Makefile cleanup
	o Remove assembler rules from top-level Makefile
	o Add scripts to generate include/linux/{version,compile}.h
	o Rules.make: Use variables for commands
	o Small Rules.make cleanup
	o Rules.make: check for changed command line
	o Makefile cleanup: Don't rebuild init/version.o on each build
	o IA64: Use standard AS rule
	o x86_64: Use standard AS rule
	o Rules.make: Remove special rule for $(export-objs)
	o Fix a typo in drivers/pcmcia/Makefile
	o Fix arch/alpha/boot AS rule
	o Makefile: fix merge
	o ISDN: Export CAPI user interface directly
	o ISDN: Remove remaining MOD_{INC,DEC}_USE_COUNT from CAPI drivers
	o Make AFLAGS_KERNEL use consistent with CFLAGS_KERNEL
	o ISDN: CAPI: Remove duplicate statistics
	o ISDN: CAPI: Remove capi_interface_user etc.
	o ISDN: CAPI: Move the notification callback
	o ISDN: Have the CAPI application alloc struct capi_appl
	o ISDN: CAPI: Pass struct capi_appl * instead of index
	o ISDN: CAPI use struct capi20_appl * in signal callback
	o ISDN: CAPI: Get rid of capi_signal mechanism
	o ISDN: AVM T1 ISA CAPI controller fix
	o Update /BitKeeper/etc/ignore
	o kbuild: Use $(CURDIR)
	o kbuild: Suppress printing of '$(MAKE) -C command' line
	o kbuild: Fix object-specific CFLAGS_foo.o
	o Small fix for net/irda/Makefile
	o Fix ext2 compilation
	o Fix some compiler warnings
	o kbuild: Remove generated .<object>.cmd files on 'make clean'
	o kbuild: Standardize building of init/*
	o kbuild: Speed up vmlinux build

<mason@suse.com>
	o reiserfs bitops warnings
	o reiserfs iput deadlock fix

Neil Brown <neilb@cse.unsw.edu.au>
	o Increase snd buffer size for UDP
	o Change MD Superblock IO to go straight to submit_bio
	o Tidy up raid5 code
	o Initial md/raid5 support for 2.5 (with bio)

<torvalds@transmeta.com>
	o Clean up %cr3 loading on x86, fix lazy TLB problem
	o Fix double i_writecount handling (Tony Luck)
	o Make generic TLB shootdown friendlier to non-x86 architectures
	o Fix OSS API emulation when sound is compiled as a module
	o Update kernel version to 2.5.17
	o New makefiles generate .*.cmd files, not .*.flags files

[PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Remove support for /dev/port altogether.

1. It is not usable with ports which require 4 byte access.

2. The same can be achieved by using capabilities and su bits and so on.

3. __m68000__ doesn't even implement it and most other non i386 archs
"implement" it but apparently don't even care about endianess issues.

4. It's not standard.

5. seek() + port access is "racy" with respect to multiple usage.

6. Nothing is using it.

... and so on and so on ...

And finally, kernel size with it:

    text    data     bss     dec     hex filename
1480587  243280  259628 1983495  1e4407 vmlinux

kernel size without it:

[root@kozaczek linux]# size vmlinux
    text    data     bss     dec     hex filename
1480229  243184  259628 1983041  1e4241 vmlinux

Which means a saving of 454 bytes :-).

[-- Attachment #2: kill-ports-2.5.17.patch --]
[-- Type: text/plain, Size: 3101 bytes --]

diff -urN linux-old/Documentation/devices.txt linux/Documentation/devices.txt
--- linux-old/Documentation/devices.txt	2002-05-21 07:07:37.000000000 +0200
+++ linux/Documentation/devices.txt	2002-05-22 11:38:47.000000000 +0200
@@ -90,7 +90,7 @@
 		  1 = /dev/mem		Physical memory access
 		  2 = /dev/kmem		Kernel virtual memory access
 		  3 = /dev/null		Null device
-		  4 = /dev/port		I/O port access
+		  4 = /dev/port		OBSOLETE - since 2.5.18
 		  5 = /dev/zero		Null byte source
 		  6 = /dev/core		OBSOLETE - replaced by /proc/kcore
 		  7 = /dev/full		Returns ENOSPC on write
diff -urN linux-old/drivers/char/mem.c linux/drivers/char/mem.c
--- linux-old/drivers/char/mem.c	2002-05-21 07:07:40.000000000 +0200
+++ linux/drivers/char/mem.c	2002-05-22 11:26:13.000000000 +0200
@@ -324,46 +324,6 @@
  	return virtr + wrote;
 }
 
-#if !defined(__mc68000__)
-static ssize_t read_port(struct file * file, char * buf,
-			 size_t count, loff_t *ppos)
-{
-	unsigned long i = *ppos;
-	char *tmp = buf;
-
-	if (verify_area(VERIFY_WRITE,buf,count))
-		return -EFAULT; 
-	while (count-- > 0 && i < 65536) {
-		if (__put_user(inb(i),tmp) < 0) 
-			return -EFAULT;  
-		i++;
-		tmp++;
-	}
-	*ppos = i;
-	return tmp-buf;
-}
-
-static ssize_t write_port(struct file * file, const char * buf,
-			  size_t count, loff_t *ppos)
-{
-	unsigned long i = *ppos;
-	const char * tmp = buf;
-
-	if (verify_area(VERIFY_READ,buf,count))
-		return -EFAULT;
-	while (count-- > 0 && i < 65536) {
-		char c;
-		if (__get_user(c, tmp)) 
-			return -EFAULT; 
-		outb(c,i);
-		i++;
-		tmp++;
-	}
-	*ppos = i;
-	return tmp-buf;
-}
-#endif
-
 static ssize_t read_null(struct file * file, char * buf,
 			 size_t count, loff_t *ppos)
 {
@@ -522,7 +482,7 @@
 	return ret;
 }
 
-static int open_port(struct inode * inode, struct file * filp)
+static int open_mem(struct inode * inode, struct file * filp)
 {
 	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
@@ -532,7 +492,6 @@
 #define full_lseek      null_lseek
 #define write_zero	write_null
 #define read_full       read_zero
-#define open_mem	open_port
 #define open_kmem	open_mem
 
 static struct file_operations mem_fops = {
@@ -557,15 +516,6 @@
 	write:		write_null,
 };
 
-#if !defined(__mc68000__)
-static struct file_operations port_fops = {
-	llseek:		memory_lseek,
-	read:		read_port,
-	write:		write_port,
-	open:		open_port,
-};
-#endif
-
 static struct file_operations zero_fops = {
 	llseek:		zero_lseek,
 	read:		read_zero,
@@ -591,11 +541,6 @@
 		case 3:
 			filp->f_op = &null_fops;
 			break;
-#if !defined(__mc68000__)
-		case 4:
-			filp->f_op = &port_fops;
-			break;
-#endif
 		case 5:
 			filp->f_op = &zero_fops;
 			break;
@@ -628,7 +573,6 @@
 	{1, "mem",     S_IRUSR | S_IWUSR | S_IRGRP, &mem_fops},
 	{2, "kmem",    S_IRUSR | S_IWUSR | S_IRGRP, &kmem_fops},
 	{3, "null",    S_IRUGO | S_IWUGO,           &null_fops},
-	{4, "port",    S_IRUSR | S_IWUSR | S_IRGRP, &port_fops},
 	{5, "zero",    S_IRUGO | S_IWUGO,           &zero_fops},
 	{7, "full",    S_IRUGO | S_IWUGO,           &full_fops},
 	{8, "random",  S_IRUGO | S_IWUSR,           &random_fops},

Re: [PATCH] 2.5.17 /dev/ports

[Paul Mackerras]

Martin Dalecki writes:

> Remove support for /dev/port altogether.

Great idea!

Paul.

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Paul Mackerras napisa?:
> Martin Dalecki writes:
> 
> 
>>Remove support for /dev/port altogether.
> 
> 
> Great idea!

I learned already that PPC people hate outb() and inb() :-).

Re: [PATCH] 2.5.17 /dev/ports

[David S. Miller]

   From: Paul Mackerras <paulus@samba.org>
   Date: Wed, 22 May 2002 20:42:47 +1000 (EST)

   Martin Dalecki writes:
   
   > Remove support for /dev/port altogether.
   
   Great idea!
   
You have my blessing too :-)

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Użytkownik David S. Miller napisał:
>    From: Paul Mackerras <paulus@samba.org>
>    Date: Wed, 22 May 2002 20:42:47 +1000 (EST)
> 
>    Martin Dalecki writes:
>    
>    > Remove support for /dev/port altogether.
>    
>    Great idea!
>    
> You have my blessing too :-)

And now I'm just eagerly awaiting the first clueless
l^Huser lurking on this list, who will flame me as usuall...
But that's no problem - I got already used to it :-).

Re: [PATCH] 2.5.17 /dev/ports

[Russell King]

On Wed, May 22, 2002 at 12:13:05PM +0200, Martin Dalecki wrote:
> And now I'm just eagerly awaiting the first clueless
> l^Huser lurking on this list, who will flame me as usuall...
> But that's no problem - I got already used to it :-).

I'm waiting on Phil Blundell to notice - I think /dev/port may get used
on ARM to emulate inb() and outb() from userspace; I don't look after
glibc so shrug.

I agree however that /dev/port is a rotten interface that needs to go.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Russell King napisa?:
> On Wed, May 22, 2002 at 12:13:05PM +0200, Martin Dalecki wrote:
> 
>>And now I'm just eagerly awaiting the first clueless
>>l^Huser lurking on this list, who will flame me as usuall...
>>But that's no problem - I got already used to it :-).
> 
> 
> I'm waiting on Phil Blundell to notice - I think /dev/port may get used
> on ARM to emulate inb() and outb() from userspace; I don't look after
> glibc so shrug.
> 
> I agree however that /dev/port is a rotten interface that needs to go.
> 

Hmm still not flames? Do they all sleep right now?

- Should I perhaps tell what I think about the glibc bloat^W coding style?

- Should I perhaps tell how "usefull" the GNU extensions to the POSIX
   standards in question are?

- Or a side note about RH's slang and popt and other useless "required"
   shared libraries?

- Is there maybe some Python module using /dev/port for precisely
   the purpose you mention. (This is actually a good candidate.)

Anyway, dear Russell (plese note the double ll!):

[root@kozaczek glibc-2.2.5]# find ./ -name "*.[ch]" -exec grep \/dev\/port 
/dev/null {} \;
[root@kozaczek glibc-2.2.5]#

[root@kozaczek glibc-2.2.5]# find ./ -name "*.[ch]" -exec grep \"port\" 
/dev/null {} \;
./hesiod/nss_hesiod/hesiod-service.c:  return lookup (portstr, "port", protocol, 
serv, buffer, buflen, errnop);
[root@kozaczek glibc-2.2.5]#
[root@kozaczek glibc-2.2.5]# find ./ -name "*.[ch]" -exec grep outb\( /dev/null 
{} \;
[root@kozaczek glibc-2.2.5]#

So I rather think that glibc may be bloated but it's not idiotic and
we have nothing to fear from it ;-)... well this time at least...
As far as I know (and I know little about ARM). It would be anwyay
unnatural to use /dev/port for the purpose you mention.
ARM io space is memmory mapped, so if any file you would
rather use /dev/kmem...

Still no flames? This silence makes me suspicious....

Re: [PATCH] 2.5.17 /dev/ports

[Richard B. Johnson]

On Wed, 22 May 2002, Martin Dalecki wrote:

> Uz.ytkownik Russell King napisa?:
> > On Wed, May 22, 2002 at 12:13:05PM +0200, Martin Dalecki wrote:
> > 
> >>And now I'm just eagerly awaiting the first clueless
> >>l^Huser lurking on this list, who will flame me as usuall...
> >>But that's no problem - I got already used to it :-).
> > 
> > 
> > I'm waiting on Phil Blundell to notice - I think /dev/port may get used
> > on ARM to emulate inb() and outb() from userspace; I don't look after
> > glibc so shrug.
> > 
> > I agree however that /dev/port is a rotten interface that needs to go.
> > 
> 
> Hmm still not flames? Do they all sleep right now?
> 
> - Should I perhaps tell what I think about the glibc bloat^W coding style?
> 
> - Should I perhaps tell how "usefull" the GNU extensions to the POSIX
>    standards in question are?
> 
> - Or a side note about RH's slang and popt and other useless "required"
>    shared libraries?
> 
> - Is there maybe some Python module using /dev/port for precisely
>    the purpose you mention. (This is actually a good candidate.)
> 
> Anyway, dear Russell (plese note the double ll!):
> 
> [root@kozaczek glibc-2.2.5]# find ./ -name "*.[ch]" -exec grep \/dev\/port 
> /dev/null {} \;
> [root@kozaczek glibc-2.2.5]#
> 
> [root@kozaczek glibc-2.2.5]# find ./ -name "*.[ch]" -exec grep \"port\" 
> /dev/null {} \;
> ./hesiod/nss_hesiod/hesiod-service.c:  return lookup (portstr, "port", protocol, 
> serv, buffer, buflen, errnop);
> [root@kozaczek glibc-2.2.5]#
> [root@kozaczek glibc-2.2.5]# find ./ -name "*.[ch]" -exec grep outb\( /dev/null 
> {} \;
> [root@kozaczek glibc-2.2.5]#
> 
> So I rather think that glibc may be bloated but it's not idiotic and
> we have nothing to fear from it ;-)... well this time at least...
> As far as I know (and I know little about ARM). It would be anwyay
> unnatural to use /dev/port for the purpose you mention.
> ARM io space is memmory mapped, so if any file you would
> rather use /dev/kmem...
> 
> Still no flames? This silence makes me suspicious....
> 

Yawn...


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: [PATCH] 2.5.17 /dev/ports

[Russell King]

On Wed, May 22, 2002 at 12:40:11PM +0200, Martin Dalecki wrote:
> ARM io space is memmory mapped, so if any file you would
> rather use /dev/kmem...

kmem = kernel memory.  That may not be the same as the physical
memory (the fact that it is at present I find mostly irrelevant here).
/dev/mem is the more correct device to use for this purpose.

> Still no flames? This silence makes me suspicious....

They're in deep sleep at the moment; try getting a metal dustbin lid and
banging it hard - maybe you'll wake the dragons from hell... 8)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> kmem = kernel memory.  That may not be the same as the physical
> memory (the fact that it is at present I find mostly irrelevant here).
> /dev/mem is the more correct device to use for this purpose.

/dev/mem is also not strictly correct. Linux in/out space is operated as
synchronous I/O operations. A dumb map of /dev/mem areas can lead to
differences if the platform concerned has to do the I/O post and wait
completion handling in software. (O_SYNC is also not enough since thats
memory caching not PCI posting)

Alan

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>kmem = kernel memory.  That may not be the same as the physical
>>memory (the fact that it is at present I find mostly irrelevant here).
>>/dev/mem is the more correct device to use for this purpose.
> 
> 
> /dev/mem is also not strictly correct. Linux in/out space is operated as
> synchronous I/O operations. A dumb map of /dev/mem areas can lead to
> differences if the platform concerned has to do the I/O post and wait
> completion handling in software. (O_SYNC is also not enough since thats
> memory caching not PCI posting)
> 

I wisper only - memzone...

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> I'm waiting on Phil Blundell to notice - I think /dev/port may get used
> on ARM to emulate inb() and outb() from userspace; I don't look after
> glibc so shrug.
> 
> I agree however that /dev/port is a rotten interface that needs to go.

The /dev/port interface is used by various apps and its a traditional
x86 in paticular unix thing. For platforms like ARM its poorly implemented
since it ought to turn into a fraction of /dev/mem and support mmap for
speedier user space in/out emulation..

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>I'm waiting on Phil Blundell to notice - I think /dev/port may get used
>>on ARM to emulate inb() and outb() from userspace; I don't look after
>>glibc so shrug.
>>
>>I agree however that /dev/port is a rotten interface that needs to go.
> 
> 
> The /dev/port interface is used by various apps and its a traditional
> x86 in paticular unix thing. For platforms like ARM its poorly implemented

Erm... unix thing? I see it only in Linux...
BTW. Just recently someone has found out that it is indeed
*poorly* implemented.


> since it ought to turn into a fraction of /dev/mem and support mmap for
> speedier user space in/out emulation..

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> > The /dev/port interface is used by various apps and its a traditional
> > x86 in paticular unix thing. For platforms like ARM its poorly implemented
> 
> Erm... unix thing? I see it only in Linux...
> BTW. Just recently someone has found out that it is indeed
> *poorly* implemented.

Well you should learn to use grep, google and a library then. The /dev/port
interface is in a whole variety of older Unixen for x86, and also in systems
like Minix.

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

>    From: Paul Mackerras <paulus@samba.org>
>    Date: Wed, 22 May 2002 20:42:47 +1000 (EST)
> 
>    Martin Dalecki writes:
>    
>    > Remove support for /dev/port altogether.
>    
>    Great idea!
>    
> You have my blessing too :-)

I'd rather you didn't break too much application code. How do you think the
perl people and the python folks do hardware control ? Or for that matter
java people trying to avoid the crawling horrors of JNI. Its also used by
libraries like libieee1284. Clock(8) uses it on some systems if the 
/dev/rtc isn't available or built in.

Xfree86 much to my suprise seems completely clean. Non Linux stuff uses it
extensively but not Linux.

ALan

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>   From: Paul Mackerras <paulus@samba.org>
>>   Date: Wed, 22 May 2002 20:42:47 +1000 (EST)
>>
>>   Martin Dalecki writes:
>>   
>>   > Remove support for /dev/port altogether.
>>   
>>   Great idea!
>>   
>>You have my blessing too :-)
> 
> 
> I'd rather you didn't break too much application code. How do you think the
> perl people and the python folks do hardware control ? Or for that matter
> java people trying to avoid the crawling horrors of JNI. Its also used by
> libraries like libieee1284. Clock(8) uses it on some systems if the 
> /dev/rtc isn't available or built in.
> 
> Xfree86 much to my suprise seems completely clean. Non Linux stuff uses it
> extensively but not Linux.

The Xfree86 people are actually sane and hold up the BSD tradition.
They don't even use /proc/bus and killed early /proc/agpgart usage!
Quite the reverse is true.

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> The Xfree86 people are actually sane and hold up the BSD tradition.
> They don't even use /proc/bus and killed early /proc/agpgart usage!
> Quite the reverse is true.

XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes

Alan

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>The Xfree86 people are actually sane and hold up the BSD tradition.
>>They don't even use /proc/bus and killed early /proc/agpgart usage!
>>Quite the reverse is true.
> 
> 
> XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
> and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
> 
> Alan

All the cases you encounter above are cases where Linux
leaks a more palatable interface.

/proc/cpuinfo for one could be replaced by dropping syslog
messages at a fixed file in /etc/ during boot - it's static after
all!.

DRI is one of the few XFree86 things which indeed
got born in the linux context. It should in fact run on
top  of either the /dev/agpgard ir /dev/fb device.
/proc/dri is a war... similar to the former /proc agp stuff..

/proc/bus - is not as bad in my opinnion :-).

Re: [PATCH] 2.5.17 /dev/ports

[Lars Marowsky-Bree]

On 2002-05-22T15:53:24,
   Martin Dalecki <dalecki@evision-ventures.com> said:

> /proc/cpuinfo for one could be replaced by dropping syslog
> messages at a fixed file in /etc/ during boot - it's static after
> all!.

It is not.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Immortality is an adequate definition of high availability for me.
	--- Gregory F. Pfister

Re: [PATCH] 2.5.17 /dev/ports

[Padraig Brady]

Martin Dalecki wrote:
> /proc/cpuinfo for one could be replaced by dropping syslog
> messages at a fixed file in /etc/ during boot - it's static after
> all!.

The new cpufreq dynamic frequency scaling
stuff changes "cpu MHz" and "bogomips" at least.

Padraig.

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Padraig Brady napisa?:
> Martin Dalecki wrote:
> 
>> /proc/cpuinfo for one could be replaced by dropping syslog
>> messages at a fixed file in /etc/ during boot - it's static after
>> all!.
> 
> 
> The new cpufreq dynamic frequency scaling
> stuff changes "cpu MHz" and "bogomips" at least.

Both are sysctl stuff -> /proc/sys/kernel/cpu/
But it's a point the data can change indeed.

Re: [PATCH] 2.5.17 /dev/ports

[Dave Jones]

On Wed, May 22, 2002 at 04:07:25PM +0200, Martin Dalecki wrote:
 > > The new cpufreq dynamic frequency scaling
 > > stuff changes "cpu MHz" and "bogomips" at least.
 > Both are sysctl stuff -> /proc/sys/kernel/cpu/

It also changes /proc/cpuinfo to remain coherent.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Dave Jones]

On Wed, May 22, 2002 at 03:53:24PM +0200, Martin Dalecki wrote:

 > > XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
 > > and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
 > All the cases you encounter above are cases where Linux
 > leaks a more palatable interface.

proc/cpuinfo -> /dev/cpu/n/cpuid driver
proc/mtrr -> /dev/cpu/mtrr if devfs is around, but given thats not the
 common case, there is no alternative.

 > /proc/cpuinfo for one could be replaced by dropping syslog
 > messages at a fixed file in /etc/ during boot 

userspace really should be using the per-cpu drivers.

 > it's static after all!.

In most cses, yes. However this is not going to stay the same forever..
1. hotplug CPUs
2. speedscaling work like cpufreq
3. enabling/disabling of features by poking /dev/cpu/n/msr is possible, and
   cpuinfo should reflect that (but currently doesn't)


    Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> /proc/cpuinfo for one could be replaced by dropping syslog
> messages at a fixed file in /etc/ during boot - it's static after
> all!.

Wrong on that one too

Re: [PATCH] 2.5.17 /dev/ports

[Pavel Machek]

Jo!

> /proc/cpuinfo for one could be replaced by dropping syslog
> messages at a fixed file in /etc/ during boot - it's static after
> all!.

cpuinfo may change at runtime -- think hot-plugging CPUs.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] 2.5.17 /dev/ports

[Alexander Viro]

On Wed, 22 May 2002, Alan Cox wrote:

> > The Xfree86 people are actually sane and hold up the BSD tradition.
> > They don't even use /proc/bus and killed early /proc/agpgart usage!
> > Quite the reverse is true.
> 
> XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
> and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes

... and while we are at flamewar-mongering, none of these files have any
business being in procfs.

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> On Wed, 22 May 2002, Alan Cox wrote:
> 
> > > The Xfree86 people are actually sane and hold up the BSD tradition.
> > > They don't even use /proc/bus and killed early /proc/agpgart usage!
> > > Quite the reverse is true.
> > 
> > XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
> > and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
> 
> ... and while we are at flamewar-mongering, none of these files have any
> business being in procfs.

That depends on how you define procfs. Linux is not Plan 9. A lot of it 
certainly is going to cleaner with a devicefs and sysctlfs

Re: [PATCH] 2.5.17 /dev/ports

[Alexander Viro]

On Wed, 22 May 2002, Alan Cox wrote:

> > ... and while we are at flamewar-mongering, none of these files have any
> > business being in procfs.
> 
> That depends on how you define procfs. Linux is not Plan 9. A lot of it 
> certainly is going to cleaner with a devicefs and sysctlfs

OK, let me put it that way:

none of these files has any business bringing the rest of procfs along
for a ride and none of them has any reason to use any code from fs/proc/*.c

Re: [PATCH] 2.5.17 /dev/ports

[Ruth Ivimey-Cook]

On Wednesday 22 May 2002 16:10, Alexander Viro wrote:
> On Wed, 22 May 2002, Alan Cox wrote:
> > > ... and while we are at flamewar-mongering, none of these files have
> > > any business being in procfs.
> >
> > That depends on how you define procfs. Linux is not Plan 9. A lot of it
> > certainly is going to cleaner with a devicefs and sysctlfs
>
> OK, let me put it that way:
>
> none of these files has any business bringing the rest of procfs along
> for a ride and none of them has any reason to use any code from fs/proc/*.c

Ok, I'll bite. Why? Note: I'm not necessarily saying I disagree, just that I 
don't know what "test" you are applying to determine whether stuf should be 
in or out?

Personally, my test is "does it provide useful information to a program or to 
a user that is not available in other ways, or where the other ways require 
an ioctl interface". 

I insert the second phrase because I do like the general principle that in 
Unix you read and write stuff to files, and procfs does provide a lot of 
extra scope for that to happen.

There is an obvious problem with formats, but that is a specification and 
discipline issue between the various developers, and not something that is 
wrong with procfs as such.

Ruth

Re: [PATCH] 2.5.17 /dev/ports

[Rusty Russell]

On Wed, 22 May 2002 10:54:25 -0400 (EDT)
Alexander Viro <viro@math.psu.edu> wrote:
> On Wed, 22 May 2002, Alan Cox wrote:
> > XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
> > and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
> 
> ... and while we are at flamewar-mongering, none of these files have any
> business being in procfs.

Let it never be said that you lack courage 8)

Let's sort this out at the kernel summit:
 dev vs. driverfs. vs proc vs sysctl vs boot params vs. module params vs netlink

Rusty.
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Rusty Russell napisa?:
> On Wed, 22 May 2002 10:54:25 -0400 (EDT)
> Alexander Viro <viro@math.psu.edu> wrote:
> 
>>On Wed, 22 May 2002, Alan Cox wrote:
>>
>>>XFree86 uses /proc/cpuinfo, /proc/bus/pci, /proc/mtrr, /proc/fb, /proc/dri
>>>and even such goodies as /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
>>
>>... and while we are at flamewar-mongering, none of these files have any
>>business being in procfs.
> 
> 
> Let it never be said that you lack courage 8)
> 
> Let's sort this out at the kernel summit:
>  dev vs. driverfs. vs proc vs sysctl vs boot params vs. module params vs netlink

There isn't that much to be discussed there.

1. /proc is for process data becouse this has inherently a tree structure and
the FS abstractis is fitting this nicely. (We can share code with the VFS layer
therefore.)

2. /proc/sys is justifyed by the fact that sysctl can share a significant
amount of code with the procfs implementation. Note this *could* be changed
by abstracting the common code out of *both* procfs and sysctl instead
of stacking sysctl on to of procfs.

3. /proc/bus is superceeded by driverfs but has a tree struct and one can life
with it.

The rest is utter crap and legacy. Technically at least.

In particular the stuff listed above is looking like things which are in
reality device access abstractions and which belongs therefore to /dev/.

The only problem here is - people without taste for the implementation,
apparently love to look at files in /proc becouse this is giving them some
feelings I can't share...

PS. Did I mention that uniformity of interfaces is quite common in good
design practice? And something beeing ASCII simple doesn't imply that
it is an uniform interface.

Re: [PATCH] 2.5.17 /dev/ports

[Rusty Russell]

In message <3CEC8FB2.8090900@evision-ventures.com> you write:
> Uz.ytkownik Rusty Russell napisa?:
> >  dev vs. driverfs. vs proc vs sysctl vs boot params vs. module params vs netlink
> 
> There isn't that much to be discussed there.

[ one page of opinionated rant deleted 8) ]

I think you've proven my point that this needs discussion, and at the
same time proven my point that this is not a place it can be discussed
8)

Thanks!
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] 2.5.17 /dev/ports

[Padraig Brady]

Martin Dalecki wrote:
> Remove support for /dev/port altogether.

FYI:

[root@pixelbeat padraig]# find /bin /usr/bin /lib /sbin /usr/sbin 
/usr/lib -maxdepth 1 -type f -perm +111 | xargs grep -l "/dev/port"
/sbin/hwclock: util-linux
/sbin/kbdrate: util-linux
/bin/watchdog: ;-)

Padraig.

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Padraig Brady napisa?:
> Martin Dalecki wrote:
> 
>> Remove support for /dev/port altogether.
> 
> 
> FYI:
> 
> [root@pixelbeat padraig]# find /bin /usr/bin /lib /sbin /usr/sbin 
> /usr/lib -maxdepth 1 -type f -perm +111 | xargs grep -l "/dev/port"
> /sbin/hwclock: util-linux
> /sbin/kbdrate: util-linux
> /bin/watchdog: ;-)

Let's have a closer look.

[root@kozaczek sbin]# rpm -qf /sbin/kbdrate
util-linux-2.11n-12
[root@kozaczek sbin]# rpm -qf /sbin/hwclock
util-linux-2.11n-12
[root@kozaczek sbin]#

/dev/null {} \;util-linux-2.11r]# find ./ -name "*.[ch]" -exec grep \/dev\/port
./po/cat-id-tbl.c:  {"Cannot open /dev/port: %s", 971},
./hwclock/cmos.c:    if ((dev_port_fd = open("/dev/port", O_RDWR)) < 0) {
./hwclock/cmos.c:      fprintf(stderr, _("Cannot open /dev/port: %s"), 
strerror(errsv));
./hwclock/clock-ppc.c: *  code and not via /dev/port (still possible via #undef 
...)."

static int
get_permissions_cmos(void) {
   int rc;

   if (use_dev_port) {
     if ((dev_port_fd = open("/dev/port", O_RDWR)) < 0) {
       int errsv = errno;
       fprintf(stderr, _("Cannot open /dev/port: %s"), strerror(errsv));
       rc = 1;
     } else
       rc = 0;
   } else {
     rc = i386_iopl(3);
     if (rc == -2) {

./hwclock/cmos.c:int use_dev_port = 0;          /* 1 for Jensen */
./hwclock/cmos.c:    use_dev_port = 1;
./hwclock/cmos.c:  if (use_dev_port) {
./hwclock/cmos.c:  if (use_dev_port) {
./hwclock/cmos.c:  if (use_dev_port) {
[root@kozaczek util-linux-2.11r]#


void
set_cmos_access(int Jensen, int funky_toy) {

   /* See whether we're dealing with a Jensen---it has a weird I/O
      system.  DEC was just learning how to build Alpha PCs.  */
   if (Jensen || is_in_cpuinfo("system type", "Jensen")) {
     use_dev_port = 1;
     clock_ctl_addr = 0x170;
     clock_data_addr = 0x171;
     if (debug) printf (_("clockport adjusted to 0x%x\n"), clock_ctl_addr);
   }

You can see from the above that the code in question
is accessing /dev/port only for the Jensen architecture...
which is:

1. Obsolete by a bright margin.

2. Very rare.

3. Should be fixed anyway.

4. Most possibly not correct anylonger.

So both of the above aplications in fact don't access /dev/port
at all at 99.9% of the systems.
Since they belong in to the util-linux category - well
we require even new versions of mount for new kernels.

Still no problem at all.

Re: [PATCH] 2.5.17 /dev/ports

[Sebastian Droege]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Wed, 22 May 2002 14:30:44 +0200
Martin Dalecki <dalecki@evision-ventures.com> wrote:

> Uz.ytkownik Padraig Brady napisa?:
> > Martin Dalecki wrote:
> > 
> >> Remove support for /dev/port altogether.
> > 
> > 
> > FYI:
> > 
> > [root@pixelbeat padraig]# find /bin /usr/bin /lib /sbin /usr/sbin 
> > /usr/lib -maxdepth 1 -type f -perm +111 | xargs grep -l "/dev/port"
> > /sbin/hwclock: util-linux
> > /sbin/kbdrate: util-linux
> > /bin/watchdog: ;-)
> 
> Let's have a closer look.
> 
[snip]
> 
> You can see from the above that the code in question
> is accessing /dev/port only for the Jensen architecture...
This is util-linux 2.11n on x86:

slomosnail:~# kbdrate 
Cannot open /dev/port: No such file or directory

slomosnail:~# hwclock 
Wed May 22 15:48:50 2002  -0.460607 seconds

Bye

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> /sbin/kbdrate: util-linux

I'd hope kbrate is using the ioctls nowdays, otherwise it will break on USB

Re: [PATCH] 2.5.17 /dev/ports

[Vojtech Pavlik]

On Wed, May 22, 2002 at 02:52:19PM +0100, Alan Cox wrote:

> > /sbin/kbdrate: util-linux
> 
> I'd hope kbrate is using the ioctls nowdays, otherwise it will break on USB

Actually, the ioctls won't work on USB, because they try to output data
to the traditional i/o ports anyway.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Vojtech Pavlik napisa?:
> On Wed, May 22, 2002 at 02:52:19PM +0100, Alan Cox wrote:
> 
> 
>>>/sbin/kbdrate: util-linux
>>
>>I'd hope kbrate is using the ioctls nowdays, otherwise it will break on USB
> 
> 
> Actually, the ioctls won't work on USB, because they try to output data
> to the traditional i/o ports anyway.


So at least we know now:

1. Kernel is bogous.
2. util-linux is bogous.

IOCTL is ineed the way to go to implement such functionality...

Re: [PATCH] 2.5.17 /dev/ports

[Vojtech Pavlik]

On Wed, May 22, 2002 at 02:51:49PM +0200, Martin Dalecki wrote:
> Uz.ytkownik Vojtech Pavlik napisa?:
> > On Wed, May 22, 2002 at 02:52:19PM +0100, Alan Cox wrote:
> > 
> > 
> >>>/sbin/kbdrate: util-linux
> >>
> >>I'd hope kbrate is using the ioctls nowdays, otherwise it will break on USB
> > 
> > 
> > Actually, the ioctls won't work on USB, because they try to output data
> > to the traditional i/o ports anyway.
> 
> 
> So at least we know now:
> 
> 1. Kernel is bogous.
> 2. util-linux is bogous.
> 
> IOCTL is ineed the way to go to implement such functionality...

Yes, the EVIOCSREP ioctl will be the one soon (works for USB keyboards
now).

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> > IOCTL is ineed the way to go to implement such functionality...
> 
> Yes, the EVIOCSREP ioctl will be the one soon (works for USB keyboards
> now).

The KBDRATE ioctl is already supported by all other keyboard drivers and
used by XFree86....

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>>IOCTL is ineed the way to go to implement such functionality...
>>
>>Yes, the EVIOCSREP ioctl will be the one soon (works for USB keyboards
>>now).
> 
> 
> The KBDRATE ioctl is already supported by all other keyboard drivers and
> used by XFree86....


Yeep. Now I even remember from the dust of my mind,
that there is a *direct mapping*
between terminal settings and ioctl numbers present in
the line discipine code. So ioctl is definitively the way to
go.

BTW.> Did I mention today that the XFree86 people are
indeed the sane ones and always choose the most
UNIX a like and proper interfaces apparently?
!Marvelously good work over a long time out there!
(Well not for font issues, in esp. in an i18n context,
but that's another story...)

Re: [PATCH] 2.5.17 /dev/ports

[Vojtech Pavlik]

On Wed, May 22, 2002 at 03:58:38PM +0100, Alan Cox wrote:

> > > IOCTL is ineed the way to go to implement such functionality...
> > 
> > Yes, the EVIOCSREP ioctl will be the one soon (works for USB keyboards
> > now).
> 
> The KBDRATE ioctl is already supported by all other keyboard drivers and
> used by XFree86....

Correct. And it'll work on USB as well once the console code is
interfaced to USB better than just by injecting scancodes into
pc_keyb.c.

KBDRATE will work on console, while EVIOCSREP will work if you open the
keyboard as an event device.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Alexander Viro]

On Wed, 22 May 2002, Martin Dalecki wrote:

> So at least we know now:
> 
> 1. Kernel is bogous.
> 2. util-linux is bogous.
> 
> IOCTL is ineed the way to go to implement such functionality...

For kbdrate???  sysctl I might see - after all, we are talking about
setting two numbers.  ioctl() to pass a couple of integers to the kernel?
No, thanks.

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alexander Viro napisa?:
> 
> On Wed, 22 May 2002, Martin Dalecki wrote:
> 
> 
>>So at least we know now:
>>
>>1. Kernel is bogous.
>>2. util-linux is bogous.
>>
>>IOCTL is ineed the way to go to implement such functionality...
> 
> 
> For kbdrate???  sysctl I might see - after all, we are talking about
> setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> No, thanks.

Portable along architectures - no thanks?
Portbale along different devices and device driver implementations - no thanks?
Not to mess with hardware with preassumtptions how it works - no thanks?
Giving PC vendors a chance to get rid of silly legacy hardware - no thanks?
Abviously documented by beeing there - no thanks?
Just one case in switch statement + few bytes for copy from user and stuff - no 
thanks?
Actual hardware functionality abstraction - no thanks?
Operating system - no thanks?

*BUT* filesystems attached to /dev/ nodes - NO THANKS indeed!

Re: [PATCH] 2.5.17 /dev/ports

[Alexander Viro]

On Wed, 22 May 2002, Martin Dalecki wrote:

> > For kbdrate???  sysctl I might see - after all, we are talking about
> > setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> > No, thanks.

If you are complaining about use of /dev/port - I completely agree that it's
crap...
 
> Portable along architectures - no thanks?
> Portbale along different devices and device driver implementations - no thanks?
> Not to mess with hardware with preassumtptions how it works - no thanks?
> Giving PC vendors a chance to get rid of silly legacy hardware - no thanks?
> Abviously documented by beeing there - no thanks?

... but WTF does it have to ioctl vs. saner mechanisms?

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alexander Viro napisa?:
> 
> On Wed, 22 May 2002, Martin Dalecki wrote:
> 
> 
>>>For kbdrate???  sysctl I might see - after all, we are talking about
>>>setting two numbers.  ioctl() to pass a couple of integers to the kernel?
>>>No, thanks.
>>
> 
> If you are complaining about use of /dev/port - I completely agree that it's
> crap...

Oh then sorry we must have missed the point.
Maybe I was just too eager for a nice flame-war which doesn't
contain the magical word BitKeeper or similar ;-)...
Anyway I'm satisfied now ;-))))...


>>Portable along architectures - no thanks?
>>Portbale along different devices and device driver implementations - no thanks?
>>Not to mess with hardware with preassumtptions how it works - no thanks?
>>Giving PC vendors a chance to get rid of silly legacy hardware - no thanks?
>>Abviously documented by beeing there - no thanks?
> 
> 
> ... but WTF does it have to ioctl vs. saner mechanisms?

It's all about the basic principle that operating systems
serve the principal purpose of abstracting hardware inferfaces
out of the actual hardware implementation and provide
*abstract* interfaces to the user space programmer. Not
more.

In this particular case it's just that ioctl fits it best.
Becouse:

1. It's already there.

2. What is there should only be fixed.

3. It's at the right level (input hardware).

4. It's more easy to implement then every thing else.

5. It's easiest to use by the application programmer.

6. I don't think that there is something saner out there.

7. Did I mention that it's already there?

But now I see that you have just certainly missed only
some previous points in this "discussion" and I wouldn't
of couse at no single second think seriously,
that the former triviallity isn't abvious to you ;-).

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alexander Viro napisa?:
> 
> On Wed, 22 May 2002, Martin Dalecki wrote:
> 
> 
>>So at least we know now:
>>
>>1. Kernel is bogous.
>>2. util-linux is bogous.
>>
>>IOCTL is ineed the way to go to implement such functionality...
> 
> 
> For kbdrate???  sysctl I might see - after all, we are talking about
> setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> No, thanks.

Ahhh and just another note - we are talking about a property of a
*device* not a property of the kernel - so ioctl (read io as device)
and certainly not sysctl (read sys as kernel).

What could be sonsidered as an *serious* alternative would
be to abstract it out even further and implement it on
the tset (terminal settings) levels. But *certainly* not sysctl.

Re: [PATCH] 2.5.17 /dev/ports

[Alexander Viro]

On Wed, 22 May 2002, Martin Dalecki wrote:

> > For kbdrate???  sysctl I might see - after all, we are talking about
> > setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> > No, thanks.
> 
> Ahhh and just another note - we are talking about a property of a
> *device* not a property of the kernel - so ioctl (read io as device)
> and certainly not sysctl (read sys as kernel).
> 
> What could be sonsidered as an *serious* alternative would
> be to abstract it out even further and implement it on
> the tset (terminal settings) levels. But *certainly* not sysctl.

Well...  Point about per-device taken, but strictly speaking we
do have e.g. per-interface sysctls, etc.

Re: [PATCH] 2.5.17 /dev/ports

[James Simmons]

> > For kbdrate???  sysctl I might see - after all, we are talking about
> > setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> > No, thanks.
> 
> Ahhh and just another note - we are talking about a property of a
> *device* not a property of the kernel - so ioctl (read io as device)
> and certainly not sysctl (read sys as kernel).
> 
> What could be sonsidered as an *serious* alternative would
> be to abstract it out even further and implement it on
> the tset (terminal settings) levels. But *certainly* not sysctl.

Hm. That is a interesting idea. I like it.

Re: [PATCH] 2.5.17 /dev/ports

[Vojtech Pavlik]

On Wed, May 22, 2002 at 09:59:41AM -0400, Alexander Viro wrote:

> On Wed, 22 May 2002, Martin Dalecki wrote:
> 
> > So at least we know now:
> > 
> > 1. Kernel is bogous.
> > 2. util-linux is bogous.
> > 
> > IOCTL is ineed the way to go to implement such functionality...
> 
> For kbdrate???  sysctl I might see - after all, we are talking about
> setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> No, thanks.

Sysctl won't be too good an idea if you have more than one keyboard.
It needs to be device-related, hence an ioctl.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Pavel Machek]

Hi

> > So at least we know now:
> > 
> > 1. Kernel is bogous.
> > 2. util-linux is bogous.
> > 
> > IOCTL is ineed the way to go to implement such functionality...
> 
> For kbdrate???  sysctl I might see - after all, we are talking about
> setting two numbers.  ioctl() to pass a couple of integers to the kernel?
> No, thanks.

There may be more than one keyboard in the system, so sysctl() is not 
suitable.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> On Wed, May 22, 2002 at 02:52:19PM +0100, Alan Cox wrote:
> 
> > > /sbin/kbdrate: util-linux
> > 
> > I'd hope kbrate is using the ioctls nowdays, otherwise it will break on USB
> 
> Actually, the ioctls won't work on USB, because they try to output data
> to the traditional i/o ports anyway.

The ioctl goes to the keyboard driver. They keyboard driver either
implements it, errors it or is buggy. No other path. I seem to be able to
portably set my keyboard rate on everything but USB 8)

Re: [PATCH] 2.5.17 /dev/ports

[Vojtech Pavlik]

On Wed, May 22, 2002 at 04:00:23PM +0100, Alan Cox wrote:

> > On Wed, May 22, 2002 at 02:52:19PM +0100, Alan Cox wrote:
> > 
> > > > /sbin/kbdrate: util-linux
> > > 
> > > I'd hope kbrate is using the ioctls nowdays, otherwise it will break on USB
> > 
> > Actually, the ioctls won't work on USB, because they try to output data
> > to the traditional i/o ports anyway.
> 
> The ioctl goes to the keyboard driver. They keyboard driver either
> implements it, errors it or is buggy. No other path. I seem to be able to
> portably set my keyboard rate on everything but USB 8)

Agreed, current method of interfacing USB keyboards to keyboard.c (as
implemented by keybdev.c) is a bug in itself.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Linus Torvalds]

On Wed, 22 May 2002, Martin Dalecki wrote:
>
> Remove support for /dev/port altogether.

Yes, I don't think it has actually ever been used.

It was done purely because Minix did it that way, and it wasn't even
compatible with Minix (I think Minix actually supoorted 2- and 4-byte
accesses by just doign 2- and 4-byte read/write calls, the Linux code
never did).

Everybody always used the iobitmap/iopl interfaces under Linux as far as I
know.

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

		Linus

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

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

Holler. I posted a list of examples to linux-kernel already. iopl and ioperm
are not portable in the way /dev/port is. ioperm/iopl also doesnt work
with most scripting languages, java tools trying to avoid JNI etc

I've seen it used in tools written in java, python, perl, even tcl

Other examples include libieee1284, the pic 16x84 programmer, hwclock,
older kbdrate, /sbin/clock on machines that don't have /dev/rtc.

Not everything in the world is an x86, and not every app wants to be Linux/x86
specific or use weird syscalls

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Alan Cox napisa?:
>>Anybody: if you've ever used /dev/ports, holler _now_.
> 
> 
> Holler. I posted a list of examples to linux-kernel already. iopl and ioperm
> are not portable in the way /dev/port is. ioperm/iopl also doesnt work
> with most scripting languages, java tools trying to avoid JNI etc

What?

#include <linux/io.h>
#include <stdio.h>
#include <stdlib.h>

int main(char *argv[], int argc)
{
	int port = aoit(argv[0]);
	 int byte = aoit(argv[1]);

	if (port > 0)
		return inb(port);		
	 else
			outb(port, byte);


		return 0;
}

and then syscall("/sbin/doportio")

Is certainly *NOT IMPOSSIBLE*. But it's of course too
much of a burden...

BTW> Under java it's rather hard to get around
CAP_RAWIO if you ask me without going down to JNI.

> I've seen it used in tools written in java, python, perl, even tcl
> 
> Other examples include libieee1284, the pic 16x84 programmer, hwclock,
> older kbdrate, /sbin/clock on machines that don't have /dev/rtc.

All the examples above are samples of bad coding practice - I have
uncovered already here in C what can be expected inside there!

> Not everything in the world is an x86, and not every app wants to be Linux/x86
> specific or use weird syscalls

Yes and in esp. everything in the world is a __m68000__!

Re: [PATCH] 2.5.17 /dev/ports

[Russell King]

On Wed, May 22, 2002 at 06:17:26PM +0200, Martin Dalecki wrote:
> #include <linux/io.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(char *argv[], int argc)
> {
> 	int port = aoit(argv[0]);
> 	 int byte = aoit(argv[1]);
> 
> 	if (port > 0)
> 		return inb(port);		
> 	 else
> 			outb(port, byte);
> 
> 
> 		return 0;
> }

Erm:

1. not checking number of arguments passed.
2. thinking argv[0] is the first arg.
3. wrong test for in/out (port > 0 -> inb, port <= 0 -> outb)
4. returning the read byte via the program status code.
5. aoit is an undefined function.
6. including linux/*.h is fundamentally wrong for any user space
   program.

That's one bug every 2 lines.  Should I continue? 8)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.17 /dev/ports

[Martin Dalecki]

Uz.ytkownik Russell King napisa?:
> On Wed, May 22, 2002 at 06:17:26PM +0200, Martin Dalecki wrote:
> 
>>#include <linux/io.h>
>>#include <stdio.h>
>>#include <stdlib.h>
>>
>>int main(char *argv[], int argc)
>>{
>>	int port = aoit(argv[0]);
>>	 int byte = aoit(argv[1]);
>>
>>	if (port > 0)
>>		return inb(port);		
>>	 else
>>			outb(port, byte);
>>
>>
>>		return 0;
>>}
> 
> 
> Erm:
> 
> 1. not checking number of arguments passed.
> 2. thinking argv[0] is the first arg.
> 3. wrong test for in/out (port > 0 -> inb, port <= 0 -> outb)
> 4. returning the read byte via the program status code.
> 5. aoit is an undefined function.
> 6. including linux/*.h is fundamentally wrong for any user space
>    program.
> 
> That's one bug every 2 lines.  Should I continue? 8)

Where the *hell* - did I say that the above program was supposed
to be ANSI C ?#$@#! It's in my own
advanced/object oriented/intuitive/component/virtual machine
based mdcki-c-alike-python commercial closed source language
I'm developing to provide a replacement base for the next
generation of Rudy102 distro configuration utilities if you ask. OK?

BTW.> I'm sure it will bite the pants out of C# in the year 2100 where I
have scheduled it for the first public release.

Any questions remaining?

Re: [PATCH] 2.5.17 /dev/ports

[Alexander Viro]

On Wed, 22 May 2002, Russell King wrote:

> > int main(char *argv[], int argc)

> 1. not checking number of arguments passed.
> 2. thinking argv[0] is the first arg.

Sod that; thinking that _argv_ is the first argument of main(). ;-)

Re: [PATCH] 2.5.17 /dev/ports

[Alan Cox]

> BTW> Under java it's rather hard to get around
> CAP_RAWIO if you ask me without going down to JNI.

People run them as root. Thats not rocket science

> > I've seen it used in tools written in java, python, perl, even tcl
> > 
> > Other examples include libieee1284, the pic 16x84 programmer, hwclock,
> > older kbdrate, /sbin/clock on machines that don't have /dev/rtc.
> 
> All the examples above are samples of bad coding practice - I have
> uncovered already here in C what can be expected inside there!

Portable code is good practice.

> > Not everything in the world is an x86, and not every app wants to be Linux/x86
> > specific or use weird syscalls
> 
> Yes and in esp. everything in the world is a __m68000__!

When you look at the kernel codebase its abundantly obvious that its much
more "if its not 32bit with hardware managed caches, little endian, with
no more than one root pci bridge, has a 32/64bit machine word, is byte 
addressed, has sane store ordering rules, conventional not reverse mapped
mmu, machine word sized cache coherency, and no more than 3 level page
tables" and so forth its going to be hard to get it to work well.
 
A lot of that /dev/port using code is portable to everything from Minix through
most BSD's. It works on pretty much anything with PC style devices.

Alan

Re: [PATCH] 2.5.17 /dev/ports

[Riley Williams]

Hi Martin.

> #include <linux/io.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(char *argv[], int argc)
> {
>	int port = aoit(argv[0]);
>	int byte = aoit(argv[1]);
>
>	if (port > 0)
>		return inb(port);		
>	else {
>		outb(port, byte);
>		return 0;
>	}
> }

Interesting code. Did you really mean to have the program name as the
port number, or should that be argv[1] and argv[2] instead? Also, what
is it supposed to do? A quick analysis makes no sense of it.

Would the following be what you had intended?

	#include <linux/io.h>
	#include <stdio.h>
	#include <stdlib.h>

	int main(int argc, char **argv) {
	    int byte, port, result = 0;

	    switch (argc) {
		case 2:
		    port = atoi(argv[1]);
		    result = inb(port);
		    break;

		case 3:
		    port = atoi(argv[1]);
		    byte = atoi(argv[2]);
		    outb(port, byte);
		    break;

		default:
		    fprintf(stderr, "Usage: %s port [byte]\n", argv[0]);
		    break;
	    }
	    return result;
	}

Best wishes from Riley.

Re: [PATCH] 2.5.17 /dev/ports

[Vojtech Pavlik]

On Sun, May 26, 2002 at 02:53:37PM +0100, Riley Williams wrote:

> Would the following be what you had intended?
> 
> 	#include <linux/io.h>
> 	#include <stdio.h>
> 	#include <stdlib.h>
> 
> 	int main(int argc, char **argv) {
> 	    int byte, port, result = 0;

	    iopl(3);
> 
> 	    switch (argc) {
> 		case 2:
> 		    port = atoi(argv[1]);
> 		    result = inb(port);
> 		    break;
> 
> 		case 3:
> 		    port = atoi(argv[1]);
> 		    byte = atoi(argv[2]);
> 		    outb(port, byte);
> 		    break;
> 
> 		default:
> 		    fprintf(stderr, "Usage: %s port [byte]\n", argv[0]);
> 		    break;
> 	    }
> 	    return result;
> 	}

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.17 /dev/ports

[Riley Williams]

Hi Vojtech, Martin.

>> Would the following be what you had intended?
>>
>>	#include <linux/io.h>
>>	#include <stdio.h>
>>	#include <stdlib.h>
>>
>>	int main(int argc, char **argv) {
>>	    int byte, port, result = 0;
>> 
>	    iopl(3);
>>	    switch (argc) {
>>		case 2:
>>		    port = atoi(argv[1]);
>>		    result = inb(port);
>>		    break;
>>
>>		case 3:
>>		    port = atoi(argv[1]);
>>		    byte = atoi(argv[2]);
>>		    outb(port, byte);
>>		    break;
>>
>>		default:
>>		    fprintf(stderr, "Usage: %s port [byte]\n",
>>			    argv[0]);
		    result = -1;
>>		    break;
>>	    }
	    exit(result);
>>	}

Wonder how many bugs are left now those two have been squished...

Best wishes from Riley.

Re: [PATCH] 2.5.17 /dev/ports

[Martin Diehl]

On Wed, 22 May 2002, Linus Torvalds wrote:

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

For me, "hexedit /dev/port" turned out being a pretty helpful tool for
simple hardware analysis. Besides playing what-if games it's also
sometimes useful for driver testing to trigger certain paths for example.

Wouldn't it be worth keeping it opt-in (like CONFIG_NVRAM e.g.)?

Martin