On Mon, 2009-04-20 at 15:07 +0000, Martin Pitt wrote:

> Scott James Remnant [2009-04-20 14:38 -0000]:
> > But the hack fix is not going to go upstream, and you specifically
> > suggested sending it upstream.
> 
> I don't consider it a hack at all. It's a matter of style or opinion
> whether you expect the track/session counts to have any meaning if
> there is no CD in the drive at all.
> 
But does the attribute you point to only indicate that there is no CD in
the drive?  The cursory examination I've done, along with the very name
of the setting, suggests that a CD _in_the_drive_ may be "blank".

> As I said, you could set the values to zero in the kernel driver
> 
Pre-setting the values in the kernel to zero, before even checking,
instead of returning uninitialised data seems to be the "no brainer"
solution to me.

Any time I see uninitialised data, I see a bug.

> or entirely ignore them in udev if there's no CD. I don't see why the
> latter should be a hack;
> 
Because I'm not convinced that the attribute you refer to _only_ means
"no CD".

The defined interface is that the ID_CDROM_MEDIA_TRACK_COUNT variable
will be *empty* for no CD.  This clearly and unambiguously distinguishes
it from a CD with tracks (contains a non-zero numeric) and also from a
CD with no tracks (contains the number 0).

I think you need to prove that your suggested value has the same
semantics.

I do not think it does.

> infact, in the "be liberal what you accept" programming practice it's
> even the better solution, since it would allow newer udevs to run on
> older kernels, too.
> 
Postel's Law absolutely does not apply here.

The kernel and udev obey *STRICT* interface requirements between each
other, as befits the fact that udev is fundamentally the userspace
marshaller of kernel information.

If udev were to begin to loosely parse kernel information, madness would
ensue.


Plus, simply and frankly, Postel's Law is intended to apply to the
interaction between a system that you control and a system that you do
not.

We control our own kernel.

We have the source to our own kernel.

If there is a bug in our kernel, we should not work around it, we should
fix the bug at its source - In The Kernel.

> > I'm personally nervous about making a change to the *standard* udev
> > rules that hasn't been confirmed with the kernel maintainer of that
> > subsystem, and tested properly.
> 
> It was successfully tested above, and is really quite obvious, no?
> 
The tests above do not, to my satisfaction, demonstrate that this will
not cause regressions.

> > Remember, these rules are used by all subscribing distros not just
> > Ubuntu.
> 
> That's the intent. I guess other distros are happy about this fix as
> well.
> 
Please don't guess.

> > If there's a problem with them, or with the kernel, we should have a
> > much wider discussion net than just a bug that's fast-tracked into
> > an Ubuntu SRU.
> 
> I'd like to, but it's just about impossible to find an upstream bug
> tracker for udev -- it's not on bz.kernel.org, not in copyright, not
> linked in Launchpad, and google reveals nothing helpful either. Where
> should I send it to?
> 
There is no bug tracker, just use the mailing list - which is standard
practice for everything Kernel-related INCLUDING THE KERNEL ITSELF:

The appropriate mailing list is <email address hidden>

Scott
-- 
Scott James Remnant
<email address hidden>