[syslinux] [PATCH 1/1] COM32: Add stub functions for directories
H. Peter Anvin
hpa at zytor.com
Mon Jan 11 10:12:58 PST 2010
On 10/29/2008 05:20 PM, Gene Cumm wrote:
> On Wed, Oct 29, 2008 at 11:01 AM, H. Peter Anvin <hpa at zytor.com> wrote:
>> Gene Cumm wrote:
>>> Peter, it is my intention to start looking at the different syslinux
>>> variants. It seems that some, if not all, of these functions are
>>> already implemented but do not have a convenient API by which I can
>>> utilize them. This would first require extending the COMBOOT API to
>>> add these functions but then turn around and implement them to just
>>> return an error, I think by "equ comapi_err".
>> They aren't, really. There is no underlying function to do directory
>> extraction, as opposed to directory matching. This may seem like a
>> trivial distinction, but in some cases -- e.g. VFAT with its UTF-16
>> filenames -- it's not.
> I may be trying to oversimplify the code in my head but it would seem
> that file/directory matching is essentially iterating through a
> directory extraction then testing to see if the extracted filename
> matches the filename that you are searching for, stopping the
> iteration if found or continuing the iteration if not.
> When I said that it seemed like the functions exist to do the
> directory operations, I misused functions and should have said that
> the code exists. The pieces of code to be able to understand the
> filesystem are there but possibly not in a usable manner to be used by
> such a group of functions and API calls.
It is, but the notion of what a "match" is is filesystem-dependent. The
very process of doing a readdir() on a VFAT filesystem is a lossy
operation: each file in VFAT has *two* names, and one of them might not
even be representable in the boot-time character set. As such, you
can't just do a readdir() and strcmp() in generic code.
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
More information about the Syslinux