network magic blocked

[Matt Zimmerman]

On Mon, Jan 23, 2006 at 02:21:48PM +0000, Scott James Remnant wrote:
> On Thu, 2006-01-19 at 11:47 -0800, Matt Zimmerman wrote:
> 
> > Has anyone explained to udev upstream that we can't really continue this
> > way?  It was one thing to do this kind of transition once, but we can't
> > endure this every time there's a new kernel release.
> > 
> It's not actually deliberate, I think they are trying to maintain
> backwards compatibility for a certain subset of the feature set.  The
> trouble is that they're also deprecating things as they go, and simply
> that it's mostly poorly tested on older kernels.
> 
> The particular breakage for the new udev has been the removal of the
> "Logical"/"Physical" Device relationships we currently use.

Deprecated but still-working features shouldn't cause a loss of
functionality.  If they are removing things we currently use (assuming we
didn't start out using deprecated features), it doesn't seem that backward
compatibility is important enough to them.

> > Booting older kernels is something which has traditionally worked, and we go
> > to some lengths in packaging the kernels to make this possible.
> > 
> Booting an older kernel with the dapper udev should just work; obviously
> you won't get any "hotplug" support though and your /dev will be the
> plain-old static one underneath it.  I put a reasonable amount of effort
> into making this so, not in the least so I could fallback to a pre-15
> kernel if I needed to while testing <g>

What would it take to have full functionality in such a configuration?  A
lack of hotplug functionality is fairly crippling on many modern systems.

> > > It's a bit pointless for me to do any work on n-m if I can't test whether
> > > it works or not <g>
> > 
> > It's been stalled for ages, and it's now nearly too late to put into Dapper
> > at all.  Canonical owns laptops with non-Atheros wireless chipsets; how
> > about borrowing one?
> > 
> I figure we'll have enough together next week in London that we'll be
> able to once-and-for-all decide whether it's going in for dapper or not.
> It'd certainly be a "nice to have", but it's not that critical -- it
> doesn't do nearly as much *yet* as it claims it will be able to in the
> future.

What it does already today is more than worth the effort of trying to make
it work.  "Select a wireless network to connect to" is a huge laptop use
case, and even if we can provide only that, it's worthwhile.

-- 
 - mdz