Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

 

 

First page Previous page 1 2 3 4 5 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


ryao at cs

Mar 14, 2012, 4:27 PM

Post #51 of 108 (595 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/12 18:49, Greg KH wrote:
> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>> With that said, I have a few questions:
>>
>> 1. Why does no one mention the enterprise use case at all?
>
> It has been pointed out before, why constantly repeat ourselves.

Simple. No one has documented it. A webpage that makes a few vague
references to "enterprise use" does not count as documentation.

I happened to figure it out when trying to rationalize why anyone would
want this, but this is hardly obvious to those that imagine a computer
as a self-sufficient single disk system.

>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>
> unionfs is still a "work in progress", some systems can't do that yet.

That sounds like something that needs to be fixed.

>> 3. Why not let the users choose where these directories go and support
>> both locations?
>
> Because a plethera of options is a sure way to make sure that half of
> them don't work over the long run.
>
> We aren't Debian here people, we don't support "everything" :)

Gentoo provides far more options than Debian does, so this seems
somewhat contradictory to me.


> If you want to support both, great, feel free to step up and do the
> work.

Fair enough, however, I should remind you that not much will happen
without a decision from the Gentoo Council. I am willing to accept
whatever decision they make, but I think that exposing this decision to
users is something that is within our ability to do.

Portage provides use with the ability to do abstractions that other
distributions cannot do, such as permitting people to merge
/usr{bin,lib{32,64,},sbin} into /.
Attachments: signature.asc (0.88 KB)


gregkh at gentoo

Mar 14, 2012, 4:37 PM

Post #52 of 108 (596 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
> >> 3. Why not let the users choose where these directories go and support
> >> both locations?
> >
> > Because a plethera of options is a sure way to make sure that half of
> > them don't work over the long run.
> >
> > We aren't Debian here people, we don't support "everything" :)
>
> Gentoo provides far more options than Debian does, so this seems
> somewhat contradictory to me.

Not really, I don't think we support systems without udev anymore,
right? And we get away with a lot of these different "options" at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.

> > If you want to support both, great, feel free to step up and do the
> > work.
>
> Fair enough, however, I should remind you that not much will happen
> without a decision from the Gentoo Council. I am willing to accept
> whatever decision they make, but I think that exposing this decision to
> users is something that is within our ability to do.

I didn't think the Council ruled on technical questions.

In fact, how is this relevant at all anyway? It's quite simple in that
we don't support systems today with a separate /usr/ without a
initramfs/initrd. If it happens to work, wonderful, but don't expect
Gentoo developers to rewrite the upstream packages to work for this type
of unsupported systems, it's not going to happen.

Or are you referring to the "no more /bin and /sbin" thing? That's just
going to happen "naturally", one day in a few months or years, your
system will have moved to this without you even realizing it :)

> Portage provides use with the ability to do abstractions that other
> distributions cannot do, such as permitting people to merge
> /usr{bin,lib{32,64,},sbin} into /.

Sure, but that doesn't mean that the packages that are being merged will
actually work :)

greg k-h


gregkh at gentoo

Mar 14, 2012, 4:44 PM

Post #53 of 108 (596 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 11:21:44PM +0000, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH <gregkh [at] gentoo> wrote:
> > Oh, that's simple, separate-/usr-without-initramfs will not work and
> > will not be supported :)
>
> See, it's this "we're doing it this way because we know best and we
> say so" that upsets people.

Oh, and somehow "consensus" will work? No, sorry, it will not.

How about the basic FACT that today, such systems do not work, and are
not supported by a wide range of packages we support today.

Yes, some people are "lucky" in that their systems don't have those
packages, but others are not. The simple "I use a bluetooth keyboard"
is one such example.

So it's not a "we know best", it's a "it will not properly work
otherwise."

It is strange to watch people somehow think that if they complain
enough, or feel strongly enough, something is going to change here to
make this basic fact go away.

Now, to get back to what I said before, I'm done with this thread, it's
going nowhere, and it seems I'm just making it worse, my apologies. For
penance, I'll adopt the next abandoned package someone throws at me, any
suggestions?

greg k-h


zmedico at gentoo

Mar 14, 2012, 4:47 PM

Post #54 of 108 (593 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 04:21 PM, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH <gregkh [at] gentoo> wrote:
>> Oh, that's simple, separate-/usr-without-initramfs will not work and
>> will not be supported :)
>
> See, it's this "we're doing it this way because we know best and we
> say so" that upsets people.

It's more about what we're _not_ doing that what we're doing. What we're
not doing is supporting the "/ is a self-contained boot disk that is
independent of /usr" use case, simply because it's a huge maintenance
burden and it doesn't make much sense in the post-initramfs world. The
people who have a "problem" with this don't understand the burden and
have no intention of taking on the burden themselves. Even if they
wanted to take on the burden, they wouldn't be capable of it. If they
were capable of taking on this burden then they would have already
understood that the initramfs is the most reasonable solution to their
perceived problem.
--
Thanks,
Zac


ryao at cs

Mar 14, 2012, 4:51 PM

Post #55 of 108 (592 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/12 19:37, Greg KH wrote:
>> Portage provides use with the ability to do abstractions that other
>> distributions cannot do, such as permitting people to merge
>> /usr{bin,lib{32,64,},sbin} into /.
>
> Sure, but that doesn't mean that the packages that are being merged will
> actually work :)
>
> greg k-h

I proposed a way that this could work with no effort on the part of the
Gentoo developers in one of my earlier emails:

On 03/14/12 17:05, Richard Yao wrote:
> In the meantime, it should be possible to create a global usr USE flag
> that enables/disables gen_usr_ldscript. It would then be possible to
> delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
> The dynamic linker would go to / before /usr and it would be trivial to
> modify $PATH to ignore /usr entirely. Legacy software that requires
> /usr/{bin,sbin} would still work while those that want a separate /usr
> mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
> counterparts.
Attachments: signature.asc (0.88 KB)


ryao at cs

Mar 14, 2012, 4:58 PM

Post #56 of 108 (595 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/12 19:44, Greg KH wrote:
> Now, to get back to what I said before, I'm done with this thread, it's
> going nowhere, and it seems I'm just making it worse, my apologies. For
> penance, I'll adopt the next abandoned package someone throws at me, any
> suggestions?

Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering
a bug in the GNU toolchain. Few of us have time to deal with it, so it
would be much appreciated if you would take care of it. ;)
Attachments: signature.asc (0.88 KB)


gregkh at gentoo

Mar 14, 2012, 5:07 PM

Post #57 of 108 (597 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 07:58:23PM -0400, Richard Yao wrote:
> On 03/14/12 19:44, Greg KH wrote:
> > Now, to get back to what I said before, I'm done with this thread, it's
> > going nowhere, and it seems I'm just making it worse, my apologies. For
> > penance, I'll adopt the next abandoned package someone throws at me, any
> > suggestions?
>
> Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering
> a bug in the GNU toolchain. Few of us have time to deal with it, so it
> would be much appreciated if you would take care of it. ;)

grub is not an abandoned package, it's as if people don't read what I
write...


levertond at googlemail

Mar 14, 2012, 5:29 PM

Post #58 of 108 (593 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 14 March 2012 23:44, Greg KH <gregkh [at] gentoo> wrote:
> Oh, and somehow "consensus" will work?  No, sorry, it will not.

No, logical analysis will, as I said in the rest of my post which you
conveniently ignored - either we conclude with evidence that there are
no issues, which should settle the matter for reasonable people, or we
discover that there are, in which case they have to be dealt with one
way or another. I really don't see how anyone can object to that,
unless they're worried they won't like the result....

> How about the basic FACT that today, such systems do not work

This is debatable at best. You can keep screaming "but bluetooth
won't work!" until you're blue in the face, but that's not relevant at
all to people who don't use bluetooth.

> and are not supported by a wide range of packages we support today.

Isn't such support being removed by the same people who keep arguing
that it's already not supported? That's like cutting half your
employees' pay, and then insisting that you have to choice but to cut
the other half's pay as well, in order to be fair.

> Yes, some people are "lucky" in that their systems don't have those
> packages, but others are not.  The simple "I use a bluetooth keyboard"
> is one such example.

People who only have a bluetooth keyboard can set their systems up in
such a way that it works, just like how people who have / on lvm can
set their systems up in such a way that that works. That's not in
itself a reason to force it on everyone.

> It is strange to watch people somehow think that if they complain
> enough, or feel strongly enough, something is going to change here to
> make this basic fact go away.

If by "the basic fact" you mean that plenty of people are quite happy
doing what's worked just fine for years, then yes.


levertond at googlemail

Mar 14, 2012, 5:36 PM

Post #59 of 108 (593 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
> It's more about what we're _not_ doing that what we're doing.

Clearly something must have changed in udev 181 to make
/usr-without-initramfs not work anymore, and someone must have done
something to make that change happen, unless udev has aquired the
ability to evolve by itself.


zmedico at gentoo

Mar 14, 2012, 5:45 PM

Post #60 of 108 (597 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 05:36 PM, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
>> It's more about what we're _not_ doing that what we're doing.
>
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something to make that change happen, unless udev has aquired the
> ability to evolve by itself.

You're pointing your finger at udev, but the udev change is just a
symptom of a more general shift away from supporting the "/ is a
self-contained boot disk that is independent of /usr" use case.
--
Thanks,
Zac


levertond at googlemail

Mar 14, 2012, 5:49 PM

Post #61 of 108 (594 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 15 March 2012 00:45, Zac Medico <zmedico [at] gentoo> wrote:
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.

OK, so there are multiple instances of people not not doing anything
rather than just one. I think that supports my point more than it
refutes it.


ryao at cs

Mar 14, 2012, 5:58 PM

Post #62 of 108 (593 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/12 20:36, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
>> It's more about what we're _not_ doing that what we're doing.
>
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something to make that change happen, unless udev has aquired the
> ability to evolve by itself.
>

I suggest that you file a bug report regarding this for the Gentoo udev
maintainer.
Attachments: signature.asc (0.88 KB)


zmedico at gentoo

Mar 14, 2012, 6:06 PM

Post #63 of 108 (596 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 05:58 PM, Richard Yao wrote:
> On 03/14/12 20:36, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work anymore, and someone must have done
>> something to make that change happen, unless udev has aquired the
>> ability to evolve by itself.
>>
>
> I suggest that you file a bug report regarding this for the Gentoo udev
> maintainer.

RESOLVED:UPSTREAM
--
Thanks,
Zac


rich0 at gentoo

Mar 14, 2012, 6:07 PM

Post #64 of 108 (595 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao [at] cs> wrote:
>
> I proposed a way that this could work with no effort on the part of the
> Gentoo developers in one of my earlier emails:
>

Then go ahead and make it happen. If as you say no dev participation
is needed there is nothing Gentoo needs to do to support this.

On Wed, Mar 14, 2012 at 6:49 PM, Greg KH <gregkh [at] gentoo> wrote:
>
> We aren't Debian here people, we don't support "everything" :)
>
> If you want to support both, great, feel free to step up and do the
> work.
>

Gentoo is about choice, but it is largely about the choices that
people are willing to step up and maintain.

A few months ago there was a big thread and lots of devs said that
systemd isn't supported on Gentoo. Some devs stepped up and decided
to maintain it and now I'd say systemd is about as supported on Gentoo
as Prefix, FreeBSD, Sparc, or MIPS. That didn't happen because of
mailing list persuasion - it happened because a few people interested
in making it happen wrote a bunch of ebuilds. How do systemd units
end up in various packages? The people interested in seeing them
write good-quality patches and submit bugs, or otherwise work with the
maintainers to commit them.

For those who don't like the current direction, by all means create an
overlay called udev-root, mdev-boot, noinitramfs, or whatever. You
don't need anybody's permission to do it - just go on github and make
it happen. Write some good code. There are several devs here who
might even help you out with it, and nobody here is going to object to
packages going into the main tree as long as they're maintained in
accordance with Gentoo QA. Create some USE flags where you need
tie-ins to other system packages and as long as everything behaves
nicely and patches are good and maintained, I'm sure the package
maintainers will accept them.

Gentoo already gives its users a lot of choice, but it can only offer
the choices that people are willing to maintain. Right now I see a
lot of complaining and not a lot of maintaining. When I see a package
lastrited I don't moan about it - I either sigh or sign up to maintain
it. By all means make suggestions to improve the transition or write
docs, but simply posting on this list isn't likely to change the
direction the linux winds are blowing. The forces involved are much
larger than Gentoo.

Rich


zmedico at gentoo

Mar 14, 2012, 6:37 PM

Post #65 of 108 (594 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 06:07 PM, Rich Freeman wrote:
> For those who don't like the current direction, by all means create an
> overlay called udev-root, mdev-boot, noinitramfs, or whatever.

The simplest alternative to an initramfs that I can think of would be an
init wrapper like the one that I suggested a while back [1].

[1]
http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
--
Thanks,
Zac


ryao at cs

Mar 14, 2012, 6:44 PM

Post #66 of 108 (595 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/12 21:07, Rich Freeman wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao [at] cs> wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
>
> Then go ahead and make it happen. If as you say no dev participation
> is needed there is nothing Gentoo needs to do to support this.

That proposal was something that I had intended to abstract ebuild
maintainers such as myself out of the picture. I am do not have a
separate /usr filesystem, yet as an ebuild maintainer, I receive bug
reports from those that do.

If people want to guarentee that they can boot without an initramfs,
they can implement my suggestion. If they don't, then it is no problem
for me. I have already fixed things for the separate /usr crowd in my
ebuilds.
Attachments: signature.asc (0.88 KB)


ryao at cs

Mar 14, 2012, 6:49 PM

Post #67 of 108 (594 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/12 21:06, Zac Medico wrote:
> On 03/14/2012 05:58 PM, Richard Yao wrote:
>> On 03/14/12 20:36, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico <zmedico [at] gentoo> wrote:
>>>> It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in udev 181 to make
>>> /usr-without-initramfs not work anymore, and someone must have done
>>> something to make that change happen, unless udev has aquired the
>>> ability to evolve by itself.
>>>
>>
>> I suggest that you file a bug report regarding this for the Gentoo udev
>> maintainer.
>
> RESOLVED:UPSTREAM

Lets permit the udev maintainer to do that. :)
Attachments: signature.asc (0.88 KB)


zmedico at gentoo

Mar 14, 2012, 9:10 PM

Post #68 of 108 (594 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 02:05 PM, Richard Yao wrote:
> How did RedHat justify that lack of conformity that resulted from moving
> everything into /usr in the first place?

Does it really matter? What people in the
separate-/usr-without-initramfs camp really want is continued support
for the "/ is a self-contained boot disk that is independent of /usr"
use case, because without such support, the
separate-/usr-without-initramfs approach that they're accustomed to
becomes impossible.

The /usr merge [1] can be viewed as just one of many signs of a
widespread shift away from supporting the heavy burden of the "/ is a
self-contained boot disk that is independent of /usr" use case.

[1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
--
Thanks,
Zac


lu_zero at gentoo

Mar 14, 2012, 10:04 PM

Post #69 of 108 (590 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 3/14/12 10:58 AM, Matthew Summers wrote:

> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty). Every single
> person reading this thread that has not already done so needs to
> immediately go read the relevant documentation located in
> /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt,
> then and only then can a real discourse be had.

Yawn, I don't and I won't since I don't need it. Why should I?

> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
> nice to have a minimal recovery env in case mounting fails, etc, etc,
> etc.

Because at least for me is *totally* pointless.

My main system is with a single partition so I shouldn't care much, I
have a system that has a separate /usr so probably I'll have *some* pain
once I'll upgrade it if I don't merge /usr and / partitions before.

Still the whole idea brings us back to the freebsd "everything in /usr"
while would make more sense go the hurd way "everything in /" if there
is a sound reason to merge those. Beside the whole
/usr/share/id-data-du-jour-my-udev-rule-might-need and the I-want-glib
and I-want-dbus bandwagon I hadn't seen any compelling reason.

Having anything as complex as dbus for early boot sounds dangerous or frail.

lu


lu_zero at gentoo

Mar 14, 2012, 10:18 PM

Post #70 of 108 (594 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 3/14/12 4:37 PM, Greg KH wrote:
> Not really, I don't think we support systems without udev anymore,
> right? And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.

I think we support systems with launchd and devd quite well and we'd
love to support even some more.

> Sure, but that doesn't mean that the packages that are being merged will
> actually work :)

Only if upstream really wants to break them... And that is the perceived
situation, exacerbated by the past experience with a certain audio
daemon trying to do too much at the same time.

lu


lu_zero at gentoo

Mar 14, 2012, 10:24 PM

Post #71 of 108 (579 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 3/14/12 10:59 AM, Rich Freeman wrote:
> Well, anybody is welcome to create any replacement/addition for
> (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it
> good enough, perhaps others will even use it.

There is a SoC out there for that.

> Beyond that, anything else is just a suggestion. In the end the folks
> writing udev and systemd are writing code, which gets them a lot
> further than emails do... :)
>

People might be happy with what they have and might feel a bit
threatened when they have to switch away from the DE they like because
it forces on them an init system that they hate.

lu


1i5t5.duncan at cox

Mar 14, 2012, 11:33 PM

Post #72 of 108 (575 views)
Permalink
Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181] [In reply to]

Kent Fredric posted on Thu, 15 Mar 2012 09:10:53 +1300 as excerpted:

> On 15 March 2012 07:48, Duncan <1i5t5.duncan [at] cox> wrote:
>> It does, especially when it's literally the case, including a /usr/etc
>> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
>> visible of rootfs is mountpoints, nothing else, and /usr literally IS
>> the "unified system resource" filesystem.
>
> Considering this pretty much eliminates using / for anything useful,
> we might as well rename "/usr" "/c"
>
> Even if it /is/ just to confuse the windows crowd =)

LOL! I've been off of MS over a decade now, and simply don't think of
them that much any more. I had no clue what you were referencing...
until I read that last line. You rather confused me! =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman


m.gysel at gmail

Mar 15, 2012, 1:13 AM

Post #73 of 108 (573 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

Am 15.03.2012 00:37, schrieb Greg KH:
> Not really, I don't think we support systems without udev anymore,
> right? And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.

Sure Gentoo does support such systems...

# equery g virtual/dev-manager
* Searching for dev-manager in virtual ...

* dependency graph for virtual/dev-manager-0
`-- virtual/dev-manager-0 amd64
`-- sys-fs/udev-171-r5 (sys-fs/udev) amd64
`-- sys-apps/busybox-1.19.3-r1 (sys-apps/busybox) amd64 [mdev]
`-- sys-fs/devfsd-1.3.25-r9 (sys-fs/devfsd) [missing keyword]
`-- sys-fs/static-dev-0.1 (sys-fs/static-dev) amd64
`-- sys-freebsd/freebsd-sbin-9.0 (sys-freebsd/freebsd-sbin)
[missing keyword]
[ virtual/dev-manager-0 stats: packages (6), max depth (1) ]


/martin


kumba at gentoo

Mar 15, 2012, 4:04 AM

Post #74 of 108 (574 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On 03/14/2012 11:04, Greg KH wrote:

>
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly. Some programs later
> on recover and handle things better.


I'm well aware of what I run on my own box, and when something isn't
running, I figure it out pretty quickly. I tested udev-181 in a Gentoo VM
that I put together recently, giving it a separate /usr, and made sure that
CONFIG_DEVTMPFS was enbaled. The only service that failed to load properly
at startup was udev, specifically because udevadm couldn't locate libkmod
(likely because kmod installs into /usr/lib*, which wasn't available yet
because I also don't use an initramfs in my kernel). Everything else worked
fine, and udev later started properly once localmount was complete.

I even tried, out of curiosity, to tweak things and moved udev from sysinit
to boot and then to default runlevel. In 'boot', udevadm still fails to
load, so no change. In 'default', only net.lo failed because the 'lo'
device didn't yet exist until after udev was running. udev itself loaded
fine, and the networking scripts restarted themselves.

So with the one exception of networking, which in Linux, has never created
/dev nodes (has to be some historical piece on why), one almost doesn't need
udev at boot to even get things working on a very simple setup like mine.
And since udev is the one service that didn't load correctly, one COULD put
forth the hypothesis that it is udev that is "broken". But I doubt that
will get much traction, right?

This does lead me to wonder if a light-weight udev could exist that lacks
half or more of the functionality of the current udev. I'll be honest, I've
only edited my udev rules file once, and that was only when I installed a
Sun Happy Meal quad ethernet card in which all four ports utilize the same
MAC address and udev doesn't handle this very gracefully (if I had Solaris,
I could edit the card's firmware and change this setting).

Devtmpfs quite literally handles 98% of my particular usage scenario. Does
that apply to everyone? Nope. Just an interesting observation.

--
Joshua Kinard
Gentoo/MIPS
kumba [at] gentoo
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
Attachments: signature.asc (0.81 KB)


sionescu at cddr

Mar 15, 2012, 4:20 AM

Post #75 of 108 (572 views)
Permalink
Re: Re: Let's redesign the entire filesystem! [In reply to]

On Thu, 2012-03-15 at 00:29 +0000, David Leverton wrote:
> On 14 March 2012 23:44, Greg KH <gregkh [at] gentoo> wrote:
> > Oh, and somehow "consensus" will work? No, sorry, it will not.
>
> No, logical analysis will, as I said in the rest of my post which you
> conveniently ignored - either we conclude with evidence that there are
> no issues, which should settle the matter for reasonable people, or we
> discover that there are, in which case they have to be dealt with one
> way or another. I really don't see how anyone can object to that,
> unless they're worried they won't like the result....
>
> > How about the basic FACT that today, such systems do not work
>
> This is debatable at best. You can keep screaming "but bluetooth
> won't work!" until you're blue in the face, but that's not relevant at
> all to people who don't use bluetooth.

That's true, but given the need to have a "one size fits all" boot
system(for obvious practical reasons), such boot system needs to work
with bluetooth input devices

--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
Attachments: signature.asc (0.19 KB)

First page Previous page 1 2 3 4 5 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.