Udev fb[0-9]* permissions

Mark Rosenstand mark at borkware.net
Sat Oct 14 15:27:33 PDT 2006


On Mon, 2006-10-09 at 19:03 -0400, Bryan Kadzban wrote:
> Mark Rosenstand wrote:
> > Iwouldn't it make sense to take the 50-udev-default.rules from the 
> > suse directory (since they're well maintained) and the rest from the 
> > udev directory, and patch as needed, instead of "forking" all the 
> > files?
> 
> I am not aware of any way to patch "in-flight" -- if we used seds to do
> the updates, we could just sed the various files as part of the copy
> process.  But AFAIK patch only works in-place; we'd have to copy the
> files and patch them afterward.  Or patch them first, then install them.
> Either way, though, I suppose that's not a huge issue.  Actually, maybe
> patch's -o option would be helpful.
> 
> But I don't see this bug as an argument for using the SuSE rules (or
> modified SuSE rules, for that matter).  It was added years and years
> ago, way back before *any* rules were included in the udev tarball.  It
> was copied (more or less) from the MAKEDEV script.

I wasn't aware it started out like that. Explains why the rules was kept
as copies instead of patches, but now when there are generic rules
included, some reconsideration might be in place :-)

Now, basing a patch on the SUSE 50-udev-default.rules have the huge
advantage that they're both generic and well-maintained. If LFS really
is that different, I guess an external 50-udev-default.rules could be
maintained, but I think at least forking the sample rules should be
avoided.

> Yes, using "standard" rules makes it less likely to introduce gratuitous
> bugs, that's true.  But I'm not sure that the extra work of reevaluating
> each upstream release that we put into the book is worth it, either.

As I see it, the rules are mostly like a library of known device nodes.
Reevaluating each upstream release would only make sense if you do the
same for the source code. And it makes just as much sense to copy the
entire source tree into LFS svn, and synchronize it on each release, as
is currently done for the rules.

> For instance, if we did this now, we would have several patch hunks that
> serve no purpose except fixing bugs (or inconsistencies) in the current
> sample rules.  But the next release of udev will include these changes
> as well.  If we basically have to look at the whole patchset at each
> release to see which of our changes (if any) are already there, I think
> that's a lot of work.

In my POV, the correct solution is to submit any changes upstream, and
I'm very happy that you seem to do just that :-)

Anyway, if a correction/fix is significant enough, it can be patched in
LFS; otherwise just send it upstream and it will be there in the next
release.

> Today we can upgrade udev and udev-config independently (most of the
> time anyway).  If we move to patches, we'll be tying the two together
> more closely.

True, but the point of this is to get rid of udev-config. I think most
LFS-people like the fact that it's pretty distro neutral and that you
use mostly vanilla software.

> Now maybe it's no more work to merge our patchset "forward" into the
> upstream rules than merging the upstream changes "backward" into our
> rules.  But I suspect it would be more work.  It depends on the relative
> frequency of upstream changes that duplicate our patch(es), I suppose.

For the first release or two, this could be true. However the goal is to
get most of it upstream, so it's likely to require much less maintenance
in the long run.

> > In any case, calling the default rules "25-lfs.rules" is probably not
> > too good, since it contradicts with both the udev documentation and
> > other distros.
> 
> Other distros I can see; most call it *-default.rules or something
> similar.  Which would be fine, don't get me wrong.  But what does it
> contradict in the udev docs?  I don't see anything in the udev(7)
> manpage that mentions specific names for rules files.  Or isn't that
> what you meant?

I was refering to the Udev Bible, AKA writing-udev-rules.html :-)




More information about the lfs-dev mailing list