lkml.org 
[lkml]   [2000]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: reading 1 hardsector size, not one block size
Date
I do appreciate the many responses I've received to my initial query.  I'm
glad that there *is* a solution that allows me read/write one hardsector,
and I'll be implementing such in my EFI partition code after the weekend.

As for the issue of understanding a drive's true capacity and capabilities,
as opposed to what it "normally" returns, the two issues are orthogonal.
From a hardware manufacturer's point of view, for diagnostics, support, and
other reasons, it would be nice to be able to access all capabilities that a
specific disk can provide. Accessing data beyond the reported last sector
for the purposes of partition table backup, diagnostic information, etc.
could be very valuable.

Do I think that access to this "extra" disk space necessarily should be the
job of any file system layer? No. Should it be the job of the block layer,
to abstract the difference between SCSI and IDE, probably, so long as the
IDE and SCSI drivers can present the same interface for accessing the same
feature on both types of disks. In cases where IDE and SCSI disks differ,
then either a) the block layer supports one, and stub no-ops the other, or
b) it's left up to the IDE and SCSI drivers to present that feature. From
user-space, I'd prefer that a) be implemented, because I don't care if it's
a SCSI or IDE disk necessarily, but I'd want the same behavior from either.

Clearly this part of the discussion needs to be held-over until 2.5.

Again, thanks for everyone's comments. I'll be submitting a patch to enable
the EFI stuff in the near future.

Thanks,
Matt


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.763 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site