On Wed, Apr 12, 2000 at 07:53:37PM -0400, Justin Hahn wrote:
> On Wed, 12 Apr 2000, Ricky Beam wrote:
> > On Wed, 12 Apr 2000, Michael H. Warfield wrote:
> > > Now if there were only a CLEAN solution to the non-volatile
> > >attributes problem. Set permissions and ownership of a device. Device
> > If you define "clean solution" as '/usr/bin/vi'... either alter the
> > settings in the source or reset them everytime it's loaded.
> How hard is setting up devfsd?? The man page explains it in perfect detail.
It's a bitch and you're dreaming if it's anything that wasn't
anticipated in advance. Based on the devfsd man page, explain to me
exactly how to configure devsfd to create a link from ttf/{n} to ttyF{n}
any time a device in the ttf subdirectory is created in devfs. Give it
your best shot.
> It's cleaner than tarring up /dev, and it's persistent. Ideally it would
> record changes you make with chown and chmod in a database, but you could
> probably instrument that yourself (simply hook the change event to call a
> script which writes the perms in a coherent way, and then optional_include that
> at the top of devfsd.conf)
> Quite frankly, I thought this argument had died out ages ago.
With no resolution!
It's a butt-ugly kludge that falls on its ass and dies any time
the system fails to shut down properly or if you have transient devices.
One of the big things with 2.4 is improved resource management. We should
now expect something reasonable from hot swapable devices and PCMCIA and
Firewire and USB. The tar option blows goats when you factor transient
devices into the equation. The devfsd option is marginally better but
doesn't support everthing, can't be configured to support everything, and
still leaves timing windows like buckshot.
What's worse is that you can't DEPEND on it. If it always worked
in all conceivable cases, I might even accept a butt-ugly kludge like that.
If it never worked, it wouldn't be a problem. Trouble is that, if you
depend on it, you can't really tell if it worked or if it didn't. How do
you know if the last bootup was an ooops or a power failure and how do you
know what you untarred wasn't from three months ago. It's the "you don't
know" that's the killer here.
Sorry, if I'm sound a bit miffed, and I'm sure Richard will point out
why. I'm responsible for a device driver that needed the addition of support
for devfs. I did that but then discovered that devfsd didn't support
everything that was listed in devices.txt so I was screwed. Then I discovered
that devfsd could not even be configured at run time to support my devices,
so now I was screwed, blued, and tattoed until someone coded the support into
devfsd. It would seem to be a simple regex engine, but that's not how it was
coded, so everything it was not coded to support has to be added back into
the code base and the cycle cranked again. I thought with the grand cycle
of things moving from things like kerneld over to kmod that we would avoid
user land blobs required to make the kernel land things function properly.
This would appear to be a giant step back further than even kerneld (at
least that you didn't have to update kerneld every time you added a
new device).
And none of that truely fixes the non-volatile attributes problem
(or the links problem), especially with transient devices.
The arguments died down because some people got tired of beating
their heads against a wall. I was a lurker at that point and didn't
participate in the self flagulation of the participants. My driver wasn't
involved until the thing became part of the stock kernel and some asshole
came up with some threat that might require devfs in order to properly
function.
I still think devfs has good positive VALUABLE points. It really
DOES make my life simpler with a driver capable of creating a variable array
of over 520 devices. Trouble is that its proponents have not solved its
problems. They have ignored them or bandaged them over or argued their
opponents into apathetic submisssion. I want the advantages of devfs
without getting screwed in the process. We aren't there yet.
> --jeh
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- 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 : Sat Apr 15 2000 - 21:00:20 EST