On Sun, Jul 29, 2012 at 01:38:28PM +0200, Luca Barbato wrote
> Forking udev and making sure it stays as lean as possible isn't that bad.
That describes mdev to a T. No need to re-invent the wheel.
> Making mdev a bit richer and enjoy the speed advantage of busybox
> over stand alone shells co
On 07/14/2012 04:34 AM, Canek Peláez Valdés wrote:
> On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés wrote:
> [snip]
>> A lot of that is optional. The only hard dependencies are:
>>
>>> =sys-apps/kmod-5
>>> =sys-apps/util-linux-2.20
>> dev-util/gperf
>>> =dev-util/intltool-0.40.0
>> virtual/p
On 07/14/2012 03:21 AM, Olivier Crête wrote:
> Seriously, mdev is a just a bad and now useless hack, it does nothing
> more than using devtmpfs. You do not need udev for a very simple system.
> If you system is a bit more complicated, than udev is what you want. It
> works fine on millions of shipp
Ian Stakenvicius posted on Mon, 16 Jul 2012 09:53:20 -0400 as excerpted:
> ...if going this route, why not simply not bother to pivot_root out of
> the initramfs at all? or pivot_root but only into a directory structure
> still sitting in the initramfs? As long as all non-root bits are in
> sepa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/07/12 09:00 PM, Maxim Kammerer wrote:
> On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.dun...@cox.net>
> wrote:
>> Thinking in that direction does stimulate yet another idea, tho.
>> What about a squashfs root? AFAIK squashfs is read-only at u
Duncan wrote:
> Alternatively, I could reconfigure inittab to start my script first
..
> that actually sounds more complex
Use init. It would be a sensitive script. If it fails the kernel is sad.
//Peter
Michael Mol posted on Sun, 15 Jul 2012 20:57:28 -0400 as excerpted:
> This is sounding closer and closer to an on-disk liveCD.
It is, isn't it? But I'd want to keep it reasonably small, as I guess
I'd be rebuilding the squashfs pretty much whenever I updated any package
that it contained binar
The 13/07/12, William Hubbs wrote:
> What about using devtmpfs alone?
It's quiet fine for very simple systems.
--
Nicolas Sebrecht
On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Thinking in that direction does stimulate yet another idea, tho. What
> about a squashfs root? AFAIK squashfs is read-only at use time, thus
> enforcing actually mounting something else to write anything, eliminating
> many o
On Sun, Jul 15, 2012 at 8:30 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted:
>
>> Giving it a little thought, the simplest tmpfs-based root would be one
>> that defines a tarball as a the root. The system would create a tmpfs,
>> extr
Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted:
> Giving it a little thought, the simplest tmpfs-based root would be one
> that defines a tarball as a the root. The system would create a tmpfs,
> extract the tarball to it, and then use the existing fstab-sys module to
> mount
On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote
> They're seriously thinking about (and may be planning on) removing
> that option from the kernel entirely, to keep people configuring
> their first kernels from getting themselves in trouble, but of
> course that's now part of the kernel/use
On Sun, Jul 15, 2012 at 2:25 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> So I have the general idea,
> but doing it from an initr* with limited tools available will be
> interesting.
>
Dracut modules can specify any tools they need, and they will be
loaded into the initramfs. Obviously you'll want
Rich Freeman posted on Sun, 15 Jul 2012 08:30:31 -0400 as excerpted:
> Looking at the docs it seems like you'd need a hook for the cmdline
> stage that sets rootok (assuming it gets that far without a root, or if
> you set it to something like root=TMPFS). Then you'd install a hook to
> mount to
On Sat, Jul 14, 2012 at 9:02 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:
>>
>> I doubt anybody has tried it, so you'll have to experiment.
>
> "Anybody" /anybody/, or "anybody" on gentoo? FWIW, there are people
> running it in gen
Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:
> On Sat, Jul 14, 2012 at 7:38 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
>> /etc and the like mounted on top of it, operationally ro, rw remounted
>> for upd
On Sat, Jul 14, 2012 at 7:38 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
> /etc and the like mounted on top of it, operationally ro, rw remounted
> for updates?
>
> That's obviously going to take an initr*, which I've never really
Canek Peláez Valdés posted on Sat, 14 Jul 2012 16:29:19 -0500 as
excerpted:
> If your /usr is in the same partition as /, then udev and systemd
> supports your configuration *without* an initramfs. I have it like that
> in a couple of servers, and actually I only use an initramfs in my
> laptop an
Canek Peláez Valdés wrote:
> An initramfs it's just now the only supported way (by udev and
> systemd) to have a separated /usr partition.
Yes sure. I considered separate partitions in the 90s, let's just
say that I don't see the problem that many on the internet cry about.
Using multiple filesys
On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge wrote:
[snip]
> Anyone who tries to argue that initramfs would be good for me to
> have on my systems should brace themselves for a mouthful of foul
> swedish language coming their way! ;)
I don't think anyone has argued it's "good" for anyone. An init
Canek Peláez Valdés wrote:
> Seeing all the trouble some people have taken to make their systems
> work with mdev just to avoid having to use an initramfs, I really
> wonder how much effort it would have taken the simple task of learning
> one step more when updating kernels and switch to use an in
Graham Murray posted on Sat, 14 Jul 2012 07:13:56 +0100 as excerpted:
> "Walter Dnes" writes:
>
>> Do you realize this would effectively kill linux in the embedded
>> device area? Udev, even without the systemd code, is simply to large
>> for embedded devices.
>
> But surely most embedded de
On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain wrote:
> Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
> project a while ago.
>
> https://github.com/slashbeast/mdev-like-a-boss
>
> I think that it's actually working pretty good on his box.
>
> Some Coredevs from Funtoo are
"Walter Dnes" writes:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>>
>> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
>> the time
Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
project a while ago.
https://github.com/slashbeast/mdev-like-a-boss
I think that it's actually working pretty good on his box.
Some Coredevs from Funtoo are actually running with that stuff.
Sylvain
2012/7/13 William Hubbs
On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
> > On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote:
> > > mdev would need to switch to the netlink hotplug interface.
> >
> > I think that's quite unlikely, since mde
On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés wrote:
[snip]
> A lot of that is optional. The only hard dependencies are:
>
>>=sys-apps/kmod-5
>>=sys-apps/util-linux-2.20
> dev-util/gperf
>>=dev-util/intltool-0.40.0
> virtual/pkgconfig
> virtual/os-headers
>
> Everything else is optional. I
On Fri, Jul 13, 2012 at 8:28 PM, Michael Mol wrote:
> On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes wrote:
>> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
>>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes wrote:
>>> > Do you realize this would effectively kill linux in the embedd
On Fri, Jul 13, 2012 at 9:21 PM, Olivier Crête wrote:
> And on any new embedded platform, one should seriously think about using
> systemd too. It is very lean, replaces most of the giant, unmaintainable
> shellscripts that you find in many devices with smaller compiled code,
> and was designed to
On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes wrote:
> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes wrote:
>> > Do you realize this would effectively kill linux in the embedded
>> > device area? Udev, even without the systemd code,
On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes wrote:
> > Do you realize this would effectively kill linux in the embedded
> > device area? Udev, even without the systemd code, is simply to large
> > for embedded devices.
>
> What's
On Fri, 2012-07-13 at 21:10 -0400, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
>
> > I'll venture a guess the solution will be to create a shim daemon
> > which turns around and launches udev.
>
> A quicker-and-dirtier solution would be to create a shim daem
On Fri, Jul 13, 2012 at 9:10 PM, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
>
>> I'll venture a guess the solution will be to create a shim daemon
>> which turns around and launches udev.
>
> A quicker-and-dirtier solution would be to create a shim daemon th
On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
> I'll venture a guess the solution will be to create a shim daemon
> which turns around and launches udev.
A quicker-and-dirtier solution would be to create a shim daemon that
runs under the the name "udev", and passes all calls to /s
On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes wrote:
> Do you realize this would effectively kill linux in the embedded
> device area? Udev, even without the systemd code, is simply to large
> for embedded devices.
What's “too large”? Udev already looks pretty small to me (116k udevd,
50k libudev
On Fri, Jul 13, 2012 at 8:13 PM, Walter Dnes wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>>
>> I think that's quite unlikely, since mdev is not a da
On Fri, Jul 13, 2012 at 7:13 PM, Walter Dnes wrote:
> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>>
>> I think that's quite unlikely, since mdev is not a da
On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote:
> > mdev would need to switch to the netlink hotplug interface.
>
> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
> the time /proc/sys/kernel/hotplug is go
On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote:
> mdev would need to switch to the netlink hotplug interface.
I think that's quite unlikely, since mdev is not a daemon. Perhaps by
the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
settled on some early udev fork. [1]
[1]
h
On 07/13/2012 04:04 PM, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote
>
>> They're seriously thinking about (and may be planning on) removing
>> that option from the kernel entirely, to keep people configuring
>> their first kernels from getting themselves in trouble,
On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote
> They're seriously thinking about (and may be planning on) removing
> that option from the kernel entirely, to keep people configuring
> their first kernels from getting themselves in trouble, but of course
> that's now part of the kernel/use
William Hubbs posted on Thu, 12 Jul 2012 17:29:31 -0500 as excerpted:
>> And make sure that
>> /proc/sys/kernel/hotplug points to udev.
>
> If you are using udev, /proc/sys/kernel/hotplug should be empty; do not
> point this to udev.
Yes. I've not changed that setting from whatever the default
42 matches
Mail list logo
