On Wed, Nov 11, 2009 at 01:15:45AM +0100, Alexander Graf wrote: > > On 11.11.2009, at 01:09, Anthony Liguori wrote: > > > Scott Tsai wrote: > >> On Wed, Nov 11, 2009 at 1:06 AM, Luiz Capitulino <lcapitul...@redhat.com > >> > wrote: > >> > >>>> I'd certainly like to make this code useful for something other > >>>> than > >>>> developer training.
What code? Where is it at? > >>>> How about a new monitor command "thermometer_set" that works like > >>>> "mouse_move"? > >>>> "thermometer_set" would just set the temperature of the "first" > >>>> thermometer device it finds. > >>>> > >>> Couldn't the device be a parameter? > >>> > >>> And I'd suggest usb_therm_set for the name. > >>> > >>> > >> > >> Looking at the existing "mouse_set" and "mouse_move" monitor > >> commands, > >> they work on USB, PS/2 and other kinds of mice with "mouse_set" > >> selecting > >> the mouse device affected by "mouse_move". > >> So how about a new command "therm_set" which selects the thermometer > >> affected by "therm_temp" ? > >> > >> On a separate note, I understand that if a piece of code is not > >> useful enough > >> we don't want to merge it to add to the maintenance burden. > >> I still propose 'usb-gotemp' for merging because the fact that gregkh > >> could give his > >> driver tutorial several years in a roll to sizable audiences shows > >> that there are people out there > >> interested in getting into Linux driver development. > >> With this code merged, people could follow the video and slides of > >> his talk > >> without special hardware and this potentially grows the Linux > >> developer pool. > >> > > > > And if Greg decides to change the device he uses for the tutorial, > > then in a few years it's not so useful anymore? > > Well, why don't we ask him? I don't understand the context here. There is already an in-kernel driver for the gotemp usb device, that has been there for many many years. Why would you want to write a different one instead? Yes, I do use a different one for my "write a driver" tutorial, but when I give that class, I note the differences between the userspace interface for that driver, and the one that is already in the kernel. > > That said, if we position this as an example device, I think that > > makes sense. > > I personally don't think it should be a requirement for inclusion in > qemu that it's useful for years on for everyone using it. If there's a > big enough group of people using a feature it seems worthwhile. And if > Scott went through the trouble of implementing it, I'm pretty sure > there is enough of an audience around. Implementing something I wrote 4 years ago? :) thanks, greg k-h
