All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nix <nix@esperi.org.uk>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: david@lang.hm, Emmanuel Benisty <benisty.e@gmail.com>,
	Kurt H Maier <khm@sdf.org>,
	linux-kernel@vger.kernel.org
Subject: Re: udev breakages -
Date: Sat, 06 Oct 2012 20:09:54 +0100	[thread overview]
Message-ID: <87y5jjs9h9.fsf@spindle.srvr.nix> (raw)
In-Reply-To: <20121005214358.GA12736@khazad-dum.debian.net> (Henrique de Moraes Holschuh's message of "Fri, 5 Oct 2012 18:43:58 -0300")

On 5 Oct 2012, Henrique de Moraes Holschuh told this:

> On Fri, 05 Oct 2012, david@lang.hm wrote:
>> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier <khm@sdf.org> wrote:
>> >>On Wed, Oct 03, 2012 at 07:27:01PM +0000, Al Viro wrote:
>> >>>Al, that -><- close to volunteering for maintaining that FPOS kernel-side...
>> >>
>> >>This would be fantastic.
>> >
>> >And that would solve this very much worrying issue [1], quoting:
>> >"(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
>> >haven't noticed it yet. I am looking forward to the day when we can drop
>> >that support entirely.)"
>> >
>> >[1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
>> 
>> I think it's worth noting that even though udev 189 was recently
>> released, the not-yet-released Ubuntu 10.10 is going to be including
>> udev 175.
>
> So is Debian.

I'm a bit surprised they didn't stick with 168, really. Even udev 175
requires a /usr mount in the initramfs, and devtmpfs (though the latter
is easy to replace). The former is probably a good idea anyway. The
latter... for any system other than the very largest, or embedded
systems that must boot in a second or less, I can't see a benefit.

-- 
NULL && (void)

  reply	other threads:[~2012-10-06 19:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.90I1W/wmSTgRFXVG67o7Pp3+rKA@ifi.uio.no>
     [not found] ` <fa.Oszo+r/ZqdTxC2FHqqg+CRVMJ5Y@ifi.uio.no>
     [not found]   ` <fa.CoxzZZId9dJONv353c+pFG/HO8E@ifi.uio.no>
     [not found]     ` <fa.ixJ/7D7BnMK8xp7CwikX7jbmnKU@ifi.uio.no>
     [not found]       ` <fa./ubRQE7P/T+ateohnOKdDxOFhL4@ifi.uio.no>
     [not found]         ` <fa.lpiFTa5CtuIkUf2Z5eJ0YlsNwYI@ifi.uio.no>
2012-10-04 14:50           ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Kurt H Maier
2012-10-05  8:03             ` Emmanuel Benisty
2012-10-05 20:17               ` david
2012-10-05 21:43                 ` Henrique de Moraes Holschuh
2012-10-06 19:09                   ` Nix [this message]
2012-06-26  1:55 Mauro Carvalho Chehab
2012-10-02 13:03 ` udev breakages - was: " Mauro Carvalho Chehab
2012-10-02 16:33   ` Linus Torvalds
2012-10-02 22:12     ` Greg KH
2012-10-02 22:23       ` Greg KH
2012-10-02 22:47         ` Linus Torvalds
2012-10-03 15:13           ` Mauro Carvalho Chehab
2012-10-03 16:38             ` Linus Torvalds
2012-10-03 17:09               ` Al Viro
2012-10-03 17:32                 ` Linus Torvalds
2012-10-03 19:26                   ` Al Viro
2012-10-04  0:57                     ` udev breakages - Nix
2012-10-04 10:35                       ` Nix
2012-10-03 19:50                   ` udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait() Greg KH
2012-10-03 20:39                     ` Linus Torvalds
2012-10-03 22:48                       ` Andy Walls
2012-10-03 22:58                         ` Linus Torvalds
2012-10-04  2:39                           ` Kay Sievers
2012-10-04 17:29                             ` udev breakages - Eric W. Biederman
2012-10-04 17:42                               ` Greg KH
2012-10-04 19:17                                 ` Alan Cox
2012-10-10  3:19                                   ` Felipe Contreras
2012-10-10 16:08                                     ` Geert Uytterhoeven
2012-10-11  3:32                                 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y5jjs9h9.fsf@spindle.srvr.nix \
    --to=nix@esperi.org.uk \
    --cc=benisty.e@gmail.com \
    --cc=david@lang.hm \
    --cc=hmh@hmh.eng.br \
    --cc=khm@sdf.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.