Horst von Brand writes:
> Richard Gooch <rgooch@ras.ucalgary.ca> said:
> > Horst von Brand writes:
> > > Bingo! Keep devices in inodes on disk. To do persistence right, you'll have
> > > to keep them in inodes on disk anyway... so this whole kludge can go.
> > > Solves the different devices visible with different permissions in
> > > different chroot(2)s too, without any extra effort.
>
> > > You know, there were flamewars about this exact point around devfs for
> > > _years_... and no magic solution came forth, not even an idea for a
> > > workable solution.
>
> > My, you have a selective memory. I've proposed more than one workable
> > solution to this:
> >
> > - tar/untar (it may not appeal to you, and it doesn't appeal to me
> > that much either, but it will do the job)
>
> It is horrible, and breaks in any case where the machine isn't shut
> down cleanly. No dice.
It doesn't matter if you're not happy with it. Others are, and it
solves a problem they have. It's a workable solution for them.
> > - set permissions in /etc/devfsd.conf, edit to change
>
> Doesn't work at all with chmod/chown. No dice.
Again, that doesn't matter. It's a solution that works for some
people. It allows them a way of controlling permissions, and it allows
them to do it in a global way: "all devices of this type shall have
these permissions". It has the advantage of being compact.
> > - configure devfsd to automatically save/restore (possible *right
> > now*, although requires configuring, I could provide a canned
> > solution to make it easier)
>
> How would this work over crashes?
I've explained this before. You can configure devfsd to save the
persmissions to a disc-based FS. So you are as safe from crashes as
any writes to a disc-based FS.
> > - tunnel through to the underlying disc-based FS we're mounted over.
>
> Then get rid of the crud over the disk-based filesystem, which you
> wanted to get rid of in the first place.
You're being circular here.
> > You personally might not like some or all of them, but they do/will
> > *work*. They will get the job done.
>
> Work sort of, perhaps. But they don't answer to the fundamental
> question about persistence in any way that I would call clean, much
> less elegant. Sure, the disk-based /dev can become a mess, but what
> I see here is exchanging a rather well-understood (if ugly) mess
> with a whole new one, which furthermore is _different_ from the way
> the rest of the filesystem works, and how this (rarely visited, but
> critical) area works in Linux and in other Unices. And that I
> consider dangerous.
I *don't care* whether like these solutions. Just stop lying by saying
that no-one has implemented or proposed any "workable" solutions. I've
enumerated 4 solutions, which have been in place for quite a while or
have been proposed ages ago, and they work for real people. You made a
statement that no workable solution has been put forward. That is a
lie.
I'm sick and tired of your lying. Over the past two years you have
spread mis-information and lies about devfs. You have made claims
about how it works which are false to make it appear that devfs can't
do XYZ. Even after I've explained that devfs can do XYZ, you persist
in your lies. You can't plead ignorance, because I've pointed out your
factual errors. I'm not just talking about aesthetics, but fundamental
technical points about how devfs actually works.
Because you keep making false assertions that paint a misleading
picture of the "horrors" of devfs, even after being corrected, I know
that you are intent on spreading FUD, rather than participate in a
genuine debate. I seriously question your integrity.
You can disagree all you like on whether devfs is a good idea, and
I'll happily debate the issues. I don't have this problem with other
devfs detractors, even though there's been flaming, ridiculing,
swearing and many heated discussions. You seem to be unique in making
false statements on fundamental technical issues *and keep doing so
even after being corrected*. This is a dubious distinction.
After two years of this crap, I really am sick of it.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:23 EST