* incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo
@ 2006-07-21 18:59 Olaf Hering
2006-07-21 19:03 ` Michael Buesch
0 siblings, 1 reply; 6+ messages in thread
From: Olaf Hering @ 2006-07-21 18:59 UTC (permalink / raw)
To: Jason Lunz, netdev, mb
bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
driver version. I think this specific info can be obtained by other
ways.
Can you give bcm43xx a real version number and provide it via the
ethtool ioctl?
It will trigger a rebuild if the uname -r of the kernel to build
changes.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo
2006-07-21 18:59 incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo Olaf Hering
@ 2006-07-21 19:03 ` Michael Buesch
2006-07-21 19:12 ` Olaf Hering
2006-07-21 19:13 ` Jason Lunz
0 siblings, 2 replies; 6+ messages in thread
From: Michael Buesch @ 2006-07-21 19:03 UTC (permalink / raw)
To: Olaf Hering; +Cc: Jason Lunz, netdev, mb
On Friday 21 July 2006 20:59, Olaf Hering wrote:
>
> bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
> driver version. I think this specific info can be obtained by other
> ways.
> Can you give bcm43xx a real version number and provide it via the
> ethtool ioctl?
I am not going to maintain a bogus version number.
What about simply returning 1.0 and be done with it.
I don't think it matters. 1.0 is as bogus as any other value.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo
2006-07-21 19:03 ` Michael Buesch
@ 2006-07-21 19:12 ` Olaf Hering
2006-07-21 19:13 ` Jason Lunz
1 sibling, 0 replies; 6+ messages in thread
From: Olaf Hering @ 2006-07-21 19:12 UTC (permalink / raw)
To: Michael Buesch; +Cc: Jason Lunz, netdev
On Fri, Jul 21, Michael Buesch wrote:
> On Friday 21 July 2006 20:59, Olaf Hering wrote:
> >
> > bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
> > driver version. I think this specific info can be obtained by other
> > ways.
> > Can you give bcm43xx a real version number and provide it via the
> > ethtool ioctl?
>
> I am not going to maintain a bogus version number.
> What about simply returning 1.0 and be done with it.
> I don't think it matters. 1.0 is as bogus as any other value.
I'm less concerned about the actual number, just UTS_RELEASE should
disappear, and the #include.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo
2006-07-21 19:03 ` Michael Buesch
2006-07-21 19:12 ` Olaf Hering
@ 2006-07-21 19:13 ` Jason Lunz
2006-07-21 19:27 ` Michael Buesch
1 sibling, 1 reply; 6+ messages in thread
From: Jason Lunz @ 2006-07-21 19:13 UTC (permalink / raw)
To: Michael Buesch; +Cc: Olaf Hering, netdev
On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> I am not going to maintain a bogus version number.
> What about simply returning 1.0 and be done with it.
> I don't think it matters. 1.0 is as bogus as any other value.
Put it to use! Increment it whenever there's a major change in the
driver, like the locking rewrite or the init routine rewrite. At the
very least, it makes it easier to rule certain things out if a user
reports lockup or something.
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo
2006-07-21 19:13 ` Jason Lunz
@ 2006-07-21 19:27 ` Michael Buesch
2006-07-21 20:05 ` Jason Lunz
0 siblings, 1 reply; 6+ messages in thread
From: Michael Buesch @ 2006-07-21 19:27 UTC (permalink / raw)
To: Jason Lunz; +Cc: Olaf Hering, netdev
On Friday 21 July 2006 21:13, Jason Lunz wrote:
> On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> > I am not going to maintain a bogus version number.
> > What about simply returning 1.0 and be done with it.
> > I don't think it matters. 1.0 is as bogus as any other value.
>
> Put it to use! Increment it whenever there's a major change in the
What is a major change? Why only on major change? Why not on
simple changes, too? Simple changes sometimes introduce bugs, too.
> driver, like the locking rewrite or the init routine rewrite. At the
> very least, it makes it easier to rule certain things out if a user
> reports lockup or something.
What I wanted to say: I _never_ had debugging-problems, because
I did not know the source state it was compiled from.
If there is a lockup, and I don't see if a specific change
that might cause it is in or not, I simply ask him. It's _much_
easier than maintaining a bogus counter.
The version counter will cause patch hunks to fail and whatever.
It's only useless trouble.
If someone is not able to answer questions like:
"Which kernel version do you run?"
"Please look at foo.c line 234 and tell me what's there."
He does not want to debug the problem anyway. Problem solved.
Someone else will appear to help debugging it, if it's a real bug.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo
2006-07-21 19:27 ` Michael Buesch
@ 2006-07-21 20:05 ` Jason Lunz
0 siblings, 0 replies; 6+ messages in thread
From: Jason Lunz @ 2006-07-21 20:05 UTC (permalink / raw)
To: Michael Buesch; +Cc: Olaf Hering, netdev
On Fri, Jul 21, 2006 at 09:27:23PM +0200, Michael Buesch wrote:
> What is a major change? Why only on major change? Why not on
> simple changes, too? Simple changes sometimes introduce bugs, too.
the version number has whatever meaning you choose to assign to it.
Including none, if you so choose.
> What I wanted to say: I _never_ had debugging-problems, because
> I did not know the source state it was compiled from.
fair enough. The version field certainly doesn't seem to get much use in
other net drivers.
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-07-21 20:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-21 18:59 incorrect usage of UTS_RELEASE in bcm43xx_get_drvinfo Olaf Hering
2006-07-21 19:03 ` Michael Buesch
2006-07-21 19:12 ` Olaf Hering
2006-07-21 19:13 ` Jason Lunz
2006-07-21 19:27 ` Michael Buesch
2006-07-21 20:05 ` Jason Lunz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).