On 22 May 2000 jmcmullan@linuxcare.com wrote:
> As for network devices, we have Berkely Unix to thank. Although
> the premise of a separate namespace for network devices was arguably
> an excellent move at the time (don't need to worry about namespace
> collision in /dev, no need to write a new filesystem - and at that time
> many UNIX systems didn't have a VFS-style layer), it is flawed
> by its diversion from the UNIX ideal - "Everything's a File(tm)"
>
> Network devices, the network sockets, etc. were pushed into
> a namespace that could not be inspeced from userspace without
> special tools such as ifconfig, route, netstat, etc. Call me
> SysV, but I am a firm believer in presenting the network namespace
> in the UNIX tradition.
<rant>
Tell that to fsckwits who
a) added Missed'em'V IPC - magic API for shm instead of plain and simple
mmap() on files on a swappable memfs.
b) added pearls like sysfs() and zillion of other stupid warts when all
that was needed was open() and read().
c) took the original streams design (beautiful and lightweight) and had
turned it into the bloated piece of shit.
d) kept bloating the API and making it as unorthogonal as they could.
e) kept breeding ioctls for no good reason.
f) invented the abortion knows as SIGPOLL - with Missed'em'V signals'
semantics in bargain.
g) brought us byte-range locks API.
Now, who made all that mess? Precisely. Missed'em'V, aka.
"Perverts Of No Taste And What Had They Done To UNIX", rated from R to
X.
</rant>
Sorry, I've dealt with a lot of Missed'em'Visms lately and
compared to them all sucking interfaces introduced by BSD simply pale.
> Certain things are crucial for a device driver application
> API (ie, a filesystem) to present:
>
> * Topology-based lookup - What devices are on USB bus 2?
> * Superclass-based lookup - What block devices are online?
> * Class-based lookup - What IDE devices are online?
> * Instance-based lookup - Where is IDE0 on the bus layout?
_All_ of that stuff can be handled in userland. Remember another mantra?
"Don't put into the kernel things that can be done outside".
> Also, certain things are crucial for a device driver itself to
> present:
>
> * Access control - Who can do what to this device?
== who can mount fs.
> * State retreival - What is the hardware's state?
== read() on another file in the same fs.
> * State control - Set the hardware's state.
== write()...
> * I/O - Actually USE the device.
== both.
> Devfs is an excellent starting point for the change in UNIX,
> but it is just that - a starting point. It will have it's flaws,
... some 15 years after it had been done better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:21 EST