network magic blocked

[Scott James Remnant]

On Wed, 2006-01-25 at 03:32 -0800, Matt Zimmerman wrote:

> 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.
> 
It's the deprecated and removed/not-working features that would cause us
problems.  Part of the change in the "newer" udev is to match the
changes to sysfs in the "newer" kernel ... namely moving all devices to
under /sys/devices and turning the /sys/bus, /sys/class, etc. trees to
just symlinks.

And along with this came some slight "way things work" changes, and some
breakage.

I do think that backwards compatibility isn't *that* important to them
though, it's more a case of matching your kernel and udev versions
carefully at the moment; while this stuff is still in development.

In the future, things will likely change and the kernel/userspace API
will be stable, and then udev will probably stabilise too.

> > > 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.
> 
The stuff we used in hoary shipped as well, basically.  Given we don't
support such configurations, it doesn't seem worth the effort; let alone
the enormous amount of "which file do I edit?" confusion.

> > > > 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.
> 
I agree, that's why we wrote the spec to indicate that was the only
feature we're interested in -- and that all of the other "things it can
and will be able to do" (VPN, PPP, etc.) were not important to us for
dapper.

I'm still reasonably confident that we can use it, there's a lot of
people testing it and I've been chatting to many of them -- if between
Adam and I we can get madwifi-ng packaged and tested in the first hours
of the sprint we should have an entire week to play with things.

Scott
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060125/25267249/attachment.pgp