On Mon, Feb 2, 2009 at 3:42 AM, nidhi mittal <nidhimittal19@xxxxxxxxx> wrote: > sorry but my question it seems wsnt clear ... > as my ques was > > suppose i have this function > > blk_queue_hardsect_size( > request_queue_t *queue , unsigned short max ); > or some other function takes sector as parameter > there in any of these functions > how do i decide that whether i should send number sectors in terms of 512 > bytes > or in terms of my hardware size 2048 bytes .... > > how do i know that in this function communication is between kernel to block > layer > or from block layer to driver > > as in book they just write this > > "All request generated by kernel are multiple of > hardware sect size and properly aligned All the communication > from block layer and driver is in 512 bytes" > > as struct request req i get in request function .... > what should i assume of req->current_nr_sectors are they 512 byte sectors > or 2048 byte sectors > > pl clarify ....hope i m making sense.. Okay, I'm starting to actually think about your issue. 1) sectors are a feature of the connected device. (disk / optical device / etc.) 2) Drivers are for controllers. I assume some controllers will support your 2048 byte sector device and some may not. Thus I can't think of a reason you are having to write a new device driver specific to you device. So what are you trying to do: ie. Add support to all libata drivers to support 2048 byte sector devices. Think that was resolved last summer: See http://markmail.org/search/?q=non-512+sector#query:non-512%20sector+page:3+mid:y7bspkhxkmskem5l+state:results Is there a bug in the implementation? Is there a specific controllers driver that is not working? Is your device atapi, and atapi support is not there yet? Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
