Maxim S. Shatskih wrote:
>Not sure, but making devices part of the filesystem was an illogical
>hack in the first place it was done…
- saving the device access rights on the disk, and using the usual “chmod” for
devices. Try to update the device’s ACL in Windows. Requires some programming
and not trivial.
- ability of use the usual tools like “ls” for devices.
I’m not arguing that there shouldn’t be a way to perform the operations
done by standard tools on devices, but that’s different from making them
part of the filesystem, which requires useless complication in the
standard tools and/or the underlying OS.
It *is* a little weird that the driver is responsible for setting the
access rights of it’s device objects when it creates them. BTW, if you
want a graphical tool to mess with these, WinObj from sysinternals will
let you play with your device DACLs all day long.
But as a general design philosophy, wanting to apply access rights to
the devices assumes you’re going to have different access rights for
different users. For the vast majority of devices this isn’t what you
want. So don’t complicate the normal case in order to make the
extraordinary case easier.
>While devices share a very small number of things in common with files,
>they are a lot more different than they are similar.
Why? Entity which can be opened by name, supports read/write semantics and
device-specific IOCTLs.
Well… maybe because most devices don’t support read/write semantics
without torturing those semantics beyond all recognition? Most devices
that you might want exposed this way are natively read *or* write devices.
Some examples of mostly output devices where “read” semantics don’t make
much sense (except possibly for control information, which doesn’t
really have “read” semantics anyway): printers, video cards, audio cards.
Some examples of mostly input devices where “write” semantics don’t make
much sense (similar caveats): mice, keyboards, other HIDs, scanners,
CD-ROM drives :-).
And then there are all the devices that have neither sensible read nor
write semantics, like disk controllers, processors, and the large
variety of motherboard deviecs out there (bridges, host controllers,
buses, etc., etc.).
In fact, even disks and network devices don’t *really* have read/write
semantics. Files and ports have read/write semantics, but the raw
devices don’t (unless you’re completely insane)… the fact that we’ve
tortured these semantics to *seem* applicable notwithstanding…
>What “regular filesystem commands” were you interested in running on
>that namespace?
DIR. ATTRIB. And so on.
Again, I don’t deny it would be useful to have tools that did these
things for devices (actually, attrib is way too coarse to be useful, and
DIR would just be confusing for “devices” that expose numerous device
objects). It would also be nice if they were persistent :-).
But what’s the charm in having them be the *same* tools? Except for a
few rare cases, there really isn’t anything analogous to do to a device.
An MMC plugin would be much better for this. That way it would also be
hidden from casual users, which is a *very* good thing.
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.