On Thu, Mar 15, 2012 at 07:04:52AM -0400, Joshua Kinard wrote:
> Devtmpfs quite literally handles 98% of my particular usage scenario. Does
> that apply to everyone? Nope. Just an interesting observation.

devtmpfs does not handle device permissions.

As for a "smaller" udev, feel free to try, please realize that this that
is what udev used to be, before it was fixed to work properly. udev is
very small and compact, but patches to make it smaller are always
welcome.

There's always mudev if you don't want to run udev, good luck with that.

greg k-h

On Thu, Mar 15, 2012 at 08:30:49AM -0400, Rich Freeman wrote:
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces. That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be difficult to access consistently across
> reboots. In my case I had to hack a rule so that I got a symlink if
> the device was in a specific USB slot. Use case is controlling tuners
> for mythtv.

Why not use the links in /dev/serial/ which are there for this specific
reason?

greg k-h

On 03/15/2012 05:27 AM, Joshua Kinard wrote:
> On 03/14/2012 20:45, Zac Medico wrote:
>
>> On 03/14/2012 05:36 PM, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> 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.
>
>
> I think it's better to say that udev is one of the more important components
> of your average Linux system that's decided to support a unified root + /usr
> filesystem. If we were looking at some non-critical, non-boot service that
> made this decision, then we wouldn't be having this discussion.

They're intertwined though, since having a unified root implies that
there is no support for the "/ is a self-contained boot disk that is
independent of /usr" use case, and the bulk of people's opposition to
having a unified root seems to stem from their dependence on the "/ is a
self-contained boot disk that is independent of /usr" use case.

So, the question at the heart of the whole discussion is: Should we
support the "/ is a self-contained boot disk that is independent of
/usr" use case?
--
Thanks,
Zac

On Thu, Mar 15, 2012 at 10:42 AM, Greg KH <gregkh@gentoo.org> wrote:
>
> Why not use the links in /dev/serial/ which are there for this specific
> reason?
>

# ls -l /dev/serial
ls: cannot access /dev/serial: No such file or directory

Something in a newer version of udev perhaps? Or would my defining my
own symlinks end up overriding some rule elsewhere. I just added
these lines to /etc/udev/rules.d:
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca2"

Rich

On 03/15/12 08:40, Joshua Kinard wrote:
> I already looked in the tree and nothing really stands out as a suitable
> replacement for /dev management. mdev might, but it's part of busybox and
> not standalone as far as I know (at least, we don't have an independent
> package for it).

Busybox is installed as part of the system profile on amd64. You can
install mdev by doing this:

ln -s /bin/busybox /sbin/mdev

There is documentation in the busybox GIT for how to use it:

http://git.busybox.net/busybox/plain/docs/mdev.txt

On 03/15/12 08:34, Joshua Kinard wrote:
> On 03/14/2012 19:27, Richard Yao wrote:
>
>> On 03/14/12 18:49, Greg KH wrote:
>>>> 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.
>
>
> I thought UnionFS died? Or was better handled by other "tricks" involving
> filesystem overlays?

I know the UnionFS developer offline. I will ask him what the status of
unionFS is the next time I see him.

On Thu, Mar 15, 2012 at 22:45, Richard Yao <ryao@cs.stonybrook.edu> wrote:
> I know the UnionFS developer offline. I will ask him what the status of
> unionFS is the next time I see him.

Unionfs patchset is regularly released for new kernels, and bugs are
fixed. I wouldn't call the project "dead", I would call it "mature"
and "stable". I am not aware of the current state of affairs wrt.
Unionfs vs. aufs, and whether the propaganda at unionfs.org still
holds water, though. Too bad that there is no stacking filesystem in
the mainline kernel.

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

On 03/15/2012 10:41, Greg KH wrote:

>
> There's always mudev if you don't want to run udev, good luck with that.


Got a link? We don't have anything matching in the tree, and Google turns
up nothing relevant in the first few pages.

--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
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

On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao@cs.stonybrook.edu> 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@gentoo.org> 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.

In that vein... just to let you guys know that I have set up an
overlay that has allowed me to run my Gentoo machines with only
systemd: no OpenRC, no baselayout, no sysvinit:

http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

The changes are rather minimal (less than ten lines (usually a cople)
per ebuild changed from the original ebuilds in the tree), and almost
all will go away when the following bugs get fixed:

https://bugs.gentoo.org/show_bug.cgi?id=366173
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=405703
https://bugs.gentoo.org/show_bug.cgi?id=408379

Bug 373219 is specially problematic, since several scripts in packages
on the tree source /etc/init.d/functions.sh, (which lives in OpenRC),
and don't depend on OpenRC explicitly. I wrote a little script that
replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to
be working. I also wrote alternative versions of the packages on the
tree that implicitly depend on OpenRC, so they now explicitly depend
on a little package that only installs my script.

It seems to be working.

If you guys want to try it, I would love to hear some comments about
it. (Usual disclaimer; if it breaks, you get to keep all the pieces).

Oh, and obviously the only supported setups are those with /usr in the
same partition as /; or, if /usr is in a separated partition, systems
that use an initramfs to mount it.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:

[...]

> https://bugs.gentoo.org/show_bug.cgi?id=366173
> https://bugs.gentoo.org/show_bug.cgi?id=373219
> https://bugs.gentoo.org/show_bug.cgi?id=399615
> https://bugs.gentoo.org/show_bug.cgi?id=405703
> https://bugs.gentoo.org/show_bug.cgi?id=408379

Oops, sorry, fogot to use uniq.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México