On Sat, Sep 30, 2000 at 12:14:56PM -0500, Matt_Domsch@Dell.com wrote:
> 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.
Ah, this sounds like you want a special feature (ioctl or whatever) that
will allow accessing beyond the end of what Linux sees as the end of the
device? I don't think this will ever happen - you can get Linux to see
the whole space (even beyond what's reported by the drive), you can get
Linux to see the extra space as a different device, but I don't believe
it is reasonable to have an extra API for this kind of accesses.
-- Vojtech Pavlik SuSE Labs - 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/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:27 EST