[LWN Logo]
[LWN.net]
From:	 Martin Dalecki <dalecki@evision-ventures.com>
To:	 Russell King <rmk@arm.linux.org.uk>
Subject: Re: [PATCH] 2.5.17 /dev/ports
Date:	 Wed, 22 May 2002 12:40:11 +0200
Cc:	 "David S. Miller" <davem@redhat.com>, paulus@samba.org,
	 linux-kernel@vger.kernel.org

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....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/