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/