Hyper-V drivers items in the TODO file - Looking for clarification
Hank Janssen
hjanssen at microsoft.com
Wed Jan 20 21:57:29 UTC 2010
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?
- 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.
- 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?
- 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?
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.
And I appreciate everybody's patience with this. We are changing, although slowly!
Hank.
More information about the devel
mailing list