On Wed, Jan 20, 2010 at 09:57:29PM +0000, Hank Janssen wrote: > > > Greetings all, > > The world moves slowly here on the dark side, but progress is being made. > I finally pulled the right levers Internally to start working on a bunch of the > TODO items that people have added to the Hyper-V drivers, and yes that was the > disturbance you must have felt in the force. But I am hoping to get some > clarification on some of the items, specifically these; > > Please note, a lot of these questions stem from my own ignorance :) > > - use of /** when it is not a kerneldoc header > Patch will be submitted next week for fixing this. Is it standard to do > this for all API's? Or only for those re-usable/callable by other people? Randy answered this. I prefer to see that only used for public apis, and nothing else. > - audit the vmbus to verify it is working properly with the > driver model > I am not sure what is expected here. Any ideas or pointers. How about all of the /* FIXME THIS IS BROKEN */ comments I added to the code? That should give you a starting place to go off of. I also don't think you are implementing the whole vmbus code correctly, but the lack of coding style following is making it very difficult to review. That needs to be resolved first. All of the CamelCase crap needs to die. > - audit the network driver > - use existing net_device_stats struct in network device > We today use the struct, and use these fields rx_dropped, rx_packets, rx_bytes, > tx_bytes, tx_packets, tx_dropped. What additional functionality is requested? > > - checking for carrier inside open is wrong, network device API > confusion?? > Anybody able clarify what is meant with this request? These were added by a network driver developer, I suggest, when the code is cleaned up, posting it for review on the network linux driver mailing list and the developers there will be glad to explain these issues. > - audit the block driver > - audit the scsi driver > We added this to make sure that all patches that have been submitted by the > community where not breaking functionality. We submitted a few patches late > last year to fix bugs that were introduced. Today the 2.6.32 kernel has fully > working functionality for the block driver and SCSI driver. Can I submit a patch > to remove these two line items? Or is more required? Same as above. Clean up the code to make it reviewable, and then the proper developer teams need to review it for correct api usage. At first glance, I think some things are not being implemented properly due to some core api abuse, but I could be wrong. I noticed a lot of this when I forward-ported the driver to the 2.6.30 kernel, so those areas might be a place to start looking. > Again my apologies, but the amount of mountains that are being moved > internally To get to a sane way for us to work on the IC's in mainline > is nothing short of tectonic. > > No to mention that it has knocked many years of my life :) > > Also, we are writing additional functionality that I hope to release sooner > Rather than later. You can release it soon, but as stated previously, we need the basics to be working and cleaned up first before I will be able to accept any new functionality. > And I appreciate everybody's patience with this. We are changing, > although slowly! That's good to see, I was worried I was going to have to delete the code to get people's attention. Oh, that reminds me, you all do have a deadline of the start of the 2.6.34 merge window. If I don't get anything by then, I will be deleting the drivers/staging/hv tree for the 2.6.35 merge, as there has been no Microsoft produced patches for the code since the very first merge, which isn't acceptable according to the rules of the staging tree. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
