[Top][All Lists]

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

Re: Write a VFAT translator

From: Marcus Brinkmann
Subject: Re: Write a VFAT translator
Date: Fri, 08 Jun 2007 16:28:37 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/23.0.0 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Thu, 7 Jun 2007 10:31:58 +0200,
"christian nastasi" <nastasichr@gmail.com> wrote:
> first of all I have to present myself since it is my first time writing to
> this community, I have also to apologize for my English.

Be very welcome, Christian!  Your english is fine, don't let that bother you.

> I'm university
> student of computer engineering and I would like to help the HURD developing
> with my contribute. This is my first time in such a thing, though I'm a
> quite good experience in computer programming, and Thomas told me to try
> with the extension of the FAT translator to the VFAT support for
> LongFileName. So I began reading something here and there, specially to
> understand how the current FAT translator works and how Linux kernel support
> for VFAT  works. Now I want to make some questions.

> 1- the VFAT translator should be considered another implementation
> independent from the FAT, or it should use the common parts (like the linux
> kernel) from FAT(that I guess is the best solution) and implements the
> differences? This requires some re-organization, I think.

Can it be integrated into the existing FAT translator, with an option
to disable it?  If yes, I think there should only be one *FAT
translator, not two.  Reorganization is not a problem.

> 2- the FAT translator uses diskfs library(I want to know if I understand how
> it works). I will try to describe it very very simply. This diskfs uses the
> callbacks to access the FAT implementation, so we should need to have
> different implementations for these callbacks that are the VFAT ones. Is it
> correct? This will depend by the choose we made for the previous question.

The demultiplexing can be done inside the single callback function,
ie, for example in diskfs_lookup_hard or even dirscanblock.

> 3- The LFN support use unicode representation, even if the short file name
> entry is stored in ASCII. Does we have some translation functions for this
> or one should be created ad hoc (like linux kernel).

As somebody else said, iconv is your friend.  For an example how to
call it, you can look at the documentation or also in the
console/console-client of the Hurd.
> ... There many other thing that I could ask you, but don't like to have
> haste  for this developing. Do you have any suggestion or whatever you have
> to say that could be help me?

Good luck! :)

It's not a problem to ask many questions.  The more specific the
questions are, the better.  As an example, the three questions above
were excellent questions, and a pleasure to answer.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]