Re: sector size in block device drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



i m sorry but can someone give a direct clarification ....
i m unable to get my answer ...
its going in different directions ...but not able to get me through my doubt ...
i m sorry may be my understanding is lacking somewhere ...

On Mon, Feb 2, 2009 at 9:01 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
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



--
Thanks & Regards
Nidhi

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux