Mailing List Archive

Gordon Schumacher wrote:
> Is there already a way to read directly from the disk, perhaps via
> INT22/19h, using the COM32 open()/read() functions?

> If not, I'd like to propose adding the ability to do something like:
> int fd = open("//", O_RDONLY);
> to allow reading from the raw disk.
>
> I am working on building a COM32 module out of the checkisomd5 tool from
> isomd5sum, but I need a way to
> access the raw disk in order to do that.

Using the COM32 library, no. You could create a device descriptor for
it and use opendev() (I don't use filename tricks, because it prevents
the linker from doing its job.)

chain.c has code to read raw disks, obviously, but it doesn't use the
device layer. I'm not 100% sure if using the device layer is desirable,
since it's rather limited and doesn't (currently) support seeks, but
I'd be interested in hearing people's opinion on it.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

On Fri, 14 Dec 2007 17:14:26 -0800, H. Peter Anvin wrote:
> Using the COM32 library, no. You could create a device descriptor for
> it and use opendev() (I don't use filename tricks, because it prevents
> the linker from doing its job.)
>
After a bunch more digging, I'd concluded the much the same thing. I'm
puzzled what you mean about the linker though - do you mean ld? If so
what does it have to do with what we're passing to com32's open function?
> chain.c has code to read raw disks, obviously, but it doesn't use the
> device layer. I'm not 100% sure if using the device layer is desirable,
> since it's rather limited and doesn't (currently) support seeks, but
> I'd be interested in hearing people's opinion on it.
>
Well... so I have an lseek() function that works for com32 as well now,
even for seeking backwards. (To be fair I haven't tested it strenuously
yet.) I've also got some changes that allow one to use
open/read/lseek/etc. on the raw disk.

At this point, really, I have a bunch of patches to submit to y'all and
see what you think; I'm just working on getting the place to store them
set up first. Should be within the next week or so... I've been busy
busy, hehe...

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Gordon Schumacher wrote:
> On Fri, 14 Dec 2007 17:14:26 -0800, H. Peter Anvin wrote:
>> Using the COM32 library, no. You could create a device descriptor for
>> it and use opendev() (I don't use filename tricks, because it prevents
>> the linker from doing its job.)
>>
> After a bunch more digging, I'd concluded the much the same thing. I'm
> puzzled what you mean about the linker though - do you mean ld? If so
> what does it have to do with what we're passing to com32's open function?

If you're keying on *data*, like strings, then you have to have a
dispatch function somewhere, which will pull in every single device
driver in any binary.

Hence opendev(), which only pulls in the requested device drivers.

>> chain.c has code to read raw disks, obviously, but it doesn't use the
>> device layer. I'm not 100% sure if using the device layer is desirable,
>> since it's rather limited and doesn't (currently) support seeks, but
>> I'd be interested in hearing people's opinion on it.
>>
> Well... so I have an lseek() function that works for com32 as well now,
> even for seeking backwards. (To be fair I haven't tested it strenuously
> yet.) I've also got some changes that allow one to use
> open/read/lseek/etc. on the raw disk.
>
> At this point, really, I have a bunch of patches to submit to y'all and
> see what you think; I'm just working on getting the place to store them
> set up first. Should be within the next week or so... I've been busy
> busy, hehe...

OK :)

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

H. Peter Anvin <hpa@zytor.com> wrote on Sat, 15 Dec 2007 12:31:52 -0800:
> If you're keying on *data*, like strings, then you have to have a
> dispatch function somewhere, which will pull in every single device
> driver in any binary.
>
> Hence opendev(), which only pulls in the requested device drivers.
>

Do you mean that with respect to being able to open a *specific* disk?
I just was after the ability to read from the disk that syslinux is
currently running on, which doesn't seem require anything past the
INT22/19h call (at least not under isolinux, which is the only place
I've tested it).

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Gordon Schumacher wrote:
> H. Peter Anvin <hpa@zytor.com> wrote on Sat, 15 Dec 2007 12:31:52 -0800:
>> If you're keying on *data*, like strings, then you have to have a
>> dispatch function somewhere, which will pull in every single device
>> driver in any binary.
>>
>> Hence opendev(), which only pulls in the requested device drivers.
>
> Do you mean that with respect to being able to open a *specific* disk?
> I just was after the ability to read from the disk that syslinux is
> currently running on, which doesn't seem require anything past the
> INT22/19h call (at least not under isolinux, which is the only place
> I've tested it).

The underlying mechanism is independent -- I'm talking about COM32
library code.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.