24 Mar
2017
24 Mar
'17
8:33 a.m.
On 3/23/17, ron minnich <rminnich(a)gmail.com> wrote:
like larry said. I'm a grumpy old man. And lspci
is not Unix. And neither
is anything we use nowadays that begins with ls and has more than 2
letters.
In Unix, resources have names. They are visible in a name space, organized
into directories. The names can be enumerated by opening and reading a
directory. Information about them can be determined with stat. Their
contents can be read by open and read. They can be changed with open and
write.
it's a pretty simple and consistent model. And it works just fine with,
e.g., the the Plan 9 pnp device. From my point of view, if a user needs
lspci to enumerate PCI resources, it's because the kernel has fallen down
on the job by failing to support the Unix model.
While I agree 100% that all resources, including things like PCI
devices, should be exposed through special files, I still think
there's a place for commands like lspci, as long as they're
implemented as shell scripts that format information from the special
files. That's what I'm going to do in the OS I'm going to write (which
will look sort of like a cross between Plan 9 and QNX, and will be
even more filesystem-oriented than Plan 9). A lot of commands that are
binaries on other modern Unices will be shell scripts on my OS (Plan 9
does this to some extent as well).
Personally I'd say Unix started to lose its way architecturally with
the introduction of sockets in 4.2BSD. I think it's time for a new
Unix-like OS that both follows the Unix philosophy consistently and
remains compatible with conventional Unices. I'd say several of Plan
9's design decisions have held it back as a Unix successor without
providing any real advantage over a conventional Unix.