Re: Should 9aafabc7fece be reverted?

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >>>>> No, it is not driver name, but device name. That is different.
> >>>>
> >>>> My bad, that's what I meant, device names should be dynamic,
> >>>> right? Relying on them being static in software would then be
> >>>> buggy (like relying on eth0 being the right NIC everytime)?
> >>>>
> >>>> I'm not familiar with the N900 software, but IDR can give out
> >>>> different numbers and may not always give the first battery #0 (it
> >>>> does now but is that a guarantee in IDR?) and if not then what is
> >>>> the userspace response to this changing?
> >>>
> >>> In case N900 would have more bq27xxx batteries, then yes. But N900
> >>> has exactly *one* bq27200 battery, so there is no IDR problem.
> >>
> >> Right, but if IDR returns 42 instead of 0 would this then break its
> >> userspace software?
> > 
> > I think it is insane to starts generating random numbers for IDR... Hard 
> > to decide what happen if such situation occur...
> > 
> 
> That's kind of what I'm looking for though, if the userspace break is
> caused by software relying on the battery to be named "bq27200-0", then
> nothing short of hard-coding this exact name will 100% safely fix the
> N900 userspace software. And so using IDR and hoping it gives 0 is just
> a hacky work-around way of just naming the device "bq27200-0".

N900 userspace is not intended to be portable. (And actually current
kernel support does not allow writing portable userspace for a
phone. It presents _3_ power supplies to userspace. How is userspace
expected to deal with that?) 

And if you ever name the single battery bq27200-42 or bq27200-1337,
you'll have a flock of angry penguins at your doorstep.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html