udev problems

Bill's LFS Login lfsbill at nospam.dot
Sun May 23 10:54:42 PDT 2004

On Sat, 22 May 2004, DJ Lucas wrote:

> Matthew Burgess wrote:
> ><snip>

> Now one for you.  What known LFS goals and policies are we to reference?
> I chose http://www.linuxfromscratch.org/lfs/view/cvs/prologue/audience.html

*Without* meaning to side-track, ISTM that the organization docs
"Policies" should contain this. If not, then org docs should be scrapped
altogether because:

- it's not proved useful;
- several major teams did not do mission statements;
- lack of "Policies" gives rise to the need for ad-hoc docs such as
  Jeroen created;
- it also constantly causes discussions such as this one.

> Now lets take a look.
> ------------
> Education = Depends..will the user learn more on his own by first using
> static devices, or by learnig dynamic devices as taught in the book.

It's possible there would be no difference. It depends on what text and
refs are included. Just because something happens "magically" doesn't
mean it is "uneducational". That determination depends solely on if we
choose to impart knowledge that is not inherent in the use of the
component itself. E.g. a brief discussion of what major and minor
numbers represent, how they are manipulated to find drivers, etc.,
applies to all the various ways that devices are created. Udev/hotplug
inclusion just demands a few more lines of text that describes the
functionality added to the equation.

> Compact/Minimalist = HELL NO!  Another package.

Irrelevant if it replaces one.

> Optimized = No.  Another proggy running in the backround when a static
> device would suffice.

If optimized includes better utilization of i-nodes and disk space,
"Yes". Remember that CPU/RAM usage is not the only criteria for
"optimized". It is always a balance of tradeoffs. With CPU/RAM/HD being
what they are today, I think the application of the platform will be
the primary factor.

> -------------
> And a couple of more questions....
> So, now the question is wether education outweighs the other two goals
> as I believe it does.   If so, then does dynamic devices take away from
> education in comparison to creating the soon outdate static devices?

As I say above, that is our choice.

> While I would really like to see dynamic devices supported, the answer
> clearly seems the opposite to me.  I certainly hope this finally lays
> the argument to rest.

Having read *all* the posts to-date, it does. But probably not in the
way you thought IMO. See below.

> -- DJ Lucas

First, I discount Jeroen's package selection criteria. Why? Only for two
reasons. It is not a part of the organization docs and has not been
proposed as such, discussed, amended and incorporated. I believe in the
org docs because many individuals took the time to work on them as an
attempted solution to problems. One of those problems that would be
solved would be the one under discussion. Jeroen's proposal is good,
useful and needed. It should be a part of the organization docs

Second, without the completion of the "Policies" section in the org
docs, how can we know if Jeroen's proposals conflict with the org goals,
policies, ...? So, that leaves us pulling snippets from parts of the
book, old posts, people's (mis)understanding of goals, etc. to justify
the selection criteria.

That leaves me free to apply an arbitrary set of selection criteria that
I devise. The fact that mine happen to incorporate most of Jeroen's
proposed criteria is irrelevant.

Here's my take on udev inclusion.

1. Udev violates none of the 7 principles listed here

   As make-devices is justified by 1,2 in that document, so is udev.
   Therefore, there is nothing in that document that precludes udev
   (including that subsequent comments, AFAICT).

2. Arguments against udev then fall back on other things like
   "long-standing policies", phrases from the book, etc. Presuming
   those are valid justifications (which really should not be
   presumed, they should be in written "Policies" in the org docs), we
   can examine them.

3. "Stable packages": we have used the traditional meaning for this. LFS
    has grown. We have more expertise, official/wider testing, advanced
    technical investigation/experimentation and a larger group of folks
    that consistently monitor (and *may* *commit* to do so if they ever
    write their mission statements) lists. I think it would be reasonable
    for the dev/testing teams to formally designate the "stability" of
    a package vis-a-vis LFS inclusion. We have advanced, to some degree,
    beyond having to rely on other distros actions and developer
    "blessing" exclusively as the standards we use, although monitoring
    of their lists and results would still be a primary input for the
    LFS teams to consider.

    If this is considered valid, then an assertion by the dev and test
    folks that the package is stable for LFS use should be sufficient.
    If they take that duty seriously, and suppress their natural desire
    to always have the "latest and greatest", we should have good

4. "Educational": no component, or our install activities for that
   component, should be *viewed* as inherently educational or not. It
   *always* requires us to ask "do we need some discussion of ...".
   Where justified, we add it. So udev should not be discounted/accepted
   either way using this criteria of "educational".

5. "Not required": consider all the arguments about this from other
   posts as re-hashed here. My POV, as stated many times, is that LFS is
   more than a minimal required platform for continuing effort. It
   should also provide a *little* extra in the way of a "comfortable"
   environment for what may be attempted in following activities. If
   this is a valid consideration, and if we acknowledge the existence of
   the need for udev/hotplug on an ever-increasing number of our user
   platforms, then we should, at a minimum, strongly consider _at_least_
   offering this as a choice. Further, if it is decided that not a
   choice, but a requirement is appropriate, an alternative like
   make_devices can be referenced for those who deem udev/hotplug
   inappropriate for their scenario. Either way, appropriate educational
   text or references should be provided.

   Also, as mentioned, udev/hotplug will be required as much as
   MAKEDEV/make_devices is currently. We need not provide either of
   those two (mknod educational text and commands could be used instead)
   but we do. So we can/should consider udev/hotplug in

6. Not ready for prime time: as mentioned elsewhere, we now have the
   technical resources available in the dev/test area to make that
   determination independently of other distro's judgments and with
   full consideration and weight given to the udev/kernel developers'
   opinions. All that is required is that we have: confidence in the
   judgment of our dev/test teams; that we trust them to put aside their
   lust for blood and that they will consider mission-critical
   applications as part of their target audience and make qualifying
   statements appropriate for those situations.

   If we have those confidences, we are then in a position to assure
   ourselves that "official release", "not needed yet", "not stable
   enough" (as deduced from outside sources like other distros) are no
   longer the *primary* factors in LFS's selection of a package for inclusion.

7. Either the organization effort started last year has paid dividends
   that make the above considerations valid or it has not. If it has,
   then we should proceed on that basis. If not, then ...

In summary, ISTM that the true question is *not* udev or not, but what
policy shall we adopt in making such determinations. Jeroen's proposal
was a start, but begs the question of the level of confidence we
can/should place in the resources now available to the LFS project.

NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
Fix line above & use it to mail me direct.

More information about the lfs-dev mailing list