Hi,

I am creating an Open-Source thread-safe FAT file-system implementatio
called FullFAT. (http://www.worm.me.uk/fullfat/) (fullfat.googlecode.com)

The library is ultimately designed to be portable across anything that ca
compile C code.

I am providing 2 functions FF_EnterCriticalRegion() an
FF_ExitCriticalRegion().

The developer needs to modify these 2 functions so that they wor
appropriately on their platform.

* Disable System interrupts - thus preventing Kernel context swtichin
also.

However, can I use this to safely implement my own semaphore system?

What if the developer uses a dual-core embedded platform? How can
guarantee a safe atomic operation.

James

> I am providing 2 functions FF_EnterCriticalRegion() and
> FF_ExitCriticalRegion().
>
> The developer needs to modify these 2 functions so that they work
> appropriately on their platform.
>
> * Disable System interrupts - thus preventing Kernel context swtiching
> also.
>
> However, can I use this to safely implement my own semaphore system?

If these functions disable interrupts, then yes you can.


Sounds like an interesting project. How large do you anticipate the full
system to be, say on an ARM7 using GCC for an example?

Also, from your WEB site.
"Others incorrectly refuse to add support for LFN's due to Microsoft patent
issues. I have researched this, and we can implement LFN's without the risk
of a lawsuit from MS. Read up about their statement on the FAT license
agreement."

I would be interested in how you have come to this conclusion. I have asked
lots of people about this issue and the conclusion is always "um dunno, but
Microsoft do not have a history of suing for breaches, and are very unlikely
to start now". Not exactly water tight..

Microsoft white-paper on FAT32:
http://download.microsoft.com/downlo.../fatgen103.doc

The license here is what I initially read, but reading it again makes m
not so sure. I'm going to do some more research into this, and try to fin
a more definitive answer. Why does legal speak have to be so confusing!!

Anyway I don't want to get into that argument here. I'll publish m
findings along with the FullFAT library when its finished.

It should be very small, the major memory footprint comes from th
caching. Which is user configurable in sizes of multiples of 512 bytes
Minimum 1 single buffer of 512 bytes.

The code is still being written, so I cannot give any final estimates o
code size. I'm going to write an email to microsoft to try and get a plai
english explanation of the licensing.

James
[..]

On Jan 31, 2:23 pm, "james.walmsley" <ja> wrote:

> The license here is what I initially read, but reading it again makes me
> not so sure. I'm going to do some more research into this, and try to find
> a more definitive answer. Why does legal speak have to be so confusing!!

This whole issue of patents sprang up around the time the original
XBox was released.

Most embedded applications do not require LFN support, so it is always
going to be a low priority feature for me. However if someone
explicitly asks me to add it to DOSFS, I'll do it only (a) in a
private release for that person, and (b) with the written
understanding that they assume all IP implications.

"FreeRTOS.org" wrote:
>
.... snip ...
>
> Sounds like an interesting project. How large do you anticipate
> the full system to be, say on an ARM7 using GCC for an example?
>
> Also, from your WEB site.
> "Others incorrectly refuse to add support for LFN's due to
> Microsoft patent issues. I have researched this, and we can
> implement LFN's without the risk of a lawsuit from MS. Read up
> about their statement on the FAT license agreement."
>
> I would be interested in how you have come to this conclusion.
> I have asked lots of people about this issue and the conclusion
> is always "um dunno, but Microsoft do not have a history of suing
> for breaches, and are very unlikely to start now". Not exactly
> water tight..

Please don't strip attributions for any material you quote. Their
is no intimation about who 'your' represents in your message. This
denies credit, etc.

I don't remember exactly what the lifetime of a patent is in the
USA, but Microsofts patents on the LFN mechanism must be near to
running out. They appeared with W95, thus in 1995, and are at
least 14 years old now.

"james.walmsley" <james> wrote in message
news:nz2d
> Hi,
>
> I am creating an Open-Source thread-safe FAT file-system implementation
> called FullFAT. ([..]) (fullfat.googlecode.com)

Is your file system API compliant to POSIX or any other standard?

> The library is ultimately designed to be portable across anything that can
> compile C code.

:))) Naive idea.

> I am providing 2 functions FF_EnterCriticalRegion() and
> FF_ExitCriticalRegion().
>
> The developer needs to modify these 2 functions so that they work
> appropriately on their platform.
>
> * Disable System interrupts - thus preventing Kernel context swtiching
> also.

Disabling the interrupts is a bad idea anyway.

> However, can I use this to safely implement my own semaphore system?

No.

> What if the developer uses a dual-core embedded platform? How can I
> guarantee a safe atomic operation.

The only way to guarantee the atomic access is by the use of services
provided by OS.
Your FAT driver should provide the OS porting layer. You will need many
other system functions besides semaphores. Such as time related functions,
memory management, locale, share, thread local storage, etc. etc.


Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

>Hi,
>
>I am creating an Open-Source thread-safe FAT file-system implementation
>called FullFAT. ([..]) (fullfat.googlecode.com)
>
>The library is ultimately designed to be portable across anything tha
can
>compile C code.
>
>I am providing 2 functions FF_EnterCriticalRegion() and
>FF_ExitCriticalRegion().
>
>The developer needs to modify these 2 functions so that they work
>appropriately on their platform.
>
>* Disable System interrupts - thus preventing Kernel context swtiching
>also.
>
>However, can I use this to safely implement my own semaphore system?
>
>What if the developer uses a dual-core embedded platform? How can I
>guarantee a safe atomic operation.
>
>James

Hello, look at the lwIP project, they use an OS abstraction layer that
works nicely, if you use the same abstraction layer your file system
will work on any OS that already ported lwIP without extra work.

regards,
Giovanni

larwe wrote:
> On Jan 31, 2:23 pm, "james.walmsley" <ja> wrote:
>>The license here is what I initially read, but reading it again makes me
>>not so sure. I'm going to do some more research into this, and try to find
>>a more definitive answer. Why does legal speak have to be so confusing!!
>
> This whole issue of patents sprang up around the time the original
> XBox was released.
>
> Most embedded applications do not require LFN support, so it is always
> going to be a low priority feature for me.

If your embedded application intends to read memory cards / sticks with
music on them, users will expect to see long file names. At least, my
MP3 archive was the first on my FAT partitions where I left 8.3 land.

However, as far as I understand, MS' patents mostly apply to allow
coexistence of 8.3 and long file names. Most embedded applications don't
need *that*. My FAT implementation never even looks at the 8.3 names if
there is a LFN, and it only generates them to not leave the 8.3 field
blank. In contrast, Windows uses 8.3 names all the time, leading to
major nuisances such as "dir c:\*1*" showing "c:\Program Files" and
"c:\Documents and Settings", which have a "1" in their short name.


Stefan

On Feb 1, 7:37 am, Stefan Reuther <stefann> wrote:

> > Most embedded applications do not require LFN support, so it is always
> > going to be a low priority feature for me.
>
> If your embedded application intends to read memory cards / sticks with
> music on them, users will expect to see long file names. At least, my

Well, (a) the world DOES NOT need yet another MP3 player project, and
(b) the important information is in the ID3 tags, not in the filename.
Parsing the filename is the last resort if your MP3 file is missing
ID3s.

> However, as far as I understand, MS' patents mostly apply to allow
> coexistence of 8.3 and long file names. Most embedded applications don't

Correct... the patent raised the most often in this discussion talks
about the idea of maintaining two parallel databases of filenames with
links associating one with the other. But FAT with 8.3+LFNs is not the
only place MS uses this technique; they also use it for example when
serving MacOS volumes from an NT-family server.

> major nuisances such as "dir c:\*1*" showing "c:\Program Files" and
> "c:\Documents and Settings", which have a "1" in their short name.

That's a bug in the way CMD.EXE parses wildcards, though - not an
inherent FS bug. Observe that an Explorer window does not show the 8.3
equivalent for a file for which an LFN exists, and an explorer search
on a FAT volume also suppresses these 8.3 orphans.

larwe wrote:
> On Feb 1, 7:37 am, Stefan Reuther <stefann> wrote:
>>>Most embedded applications do not require LFN support, so it is always
>>>going to be a low priority feature for me.
>>
>>If your embedded application intends to read memory cards / sticks with
>>music on them, users will expect to see long file names. At least, my
>
> Well, (a) the world DOES NOT need yet another MP3 player project,

You mean, we should ignore all those millions of people wanting to buy
devices with MP3 ability and leave them to the Chinese? I'm glad my boss
disagrees.

> and (b) the important information is in the ID3 tags, not in the filename.
> Parsing the filename is the last resort if your MP3 file is missing
> ID3s.

Then how do you parse playlists? How do you display meaningful folder
names? And how do you explain your users why you display "01_-_A~1.MP3"
as a file name, gibberish they've last seen in an obsolete program ten
years ago? 99% of the MP3 files I produce don't have tags. Simply
because I'm too lazy to fill them in, and because file names work very well.

>>major nuisances such as "dir c:\*1*" showing "c:\Program Files" and
>>"c:\Documents and Settings", which have a "1" in their short name.
>
> That's a bug in the way CMD.EXE parses wildcards, though - not an
> inherent FS bug.

That bug, if you want to call it that, is in the FindFirstFile function,
and is documented in the API description (e.g. page "Searching
Filenames" in win32.hlp).


Stefan

On Feb 1, 1:07 pm, Stefan Reuther <stefann> wrote:

> > Well, (a) the world DOES NOT need yet another MP3 player project,
>
> You mean, we should ignore all those millions of people wanting to buy
> devices with MP3 ability and leave them to the Chinese? I'm glad my boss

Apple isn't Chinese :)

> Then how do you parse playlists? How do you display meaningful folder

Hmm, I forgot about that. It has been so many years that I've been in
the iPod economy (along with the majority of other consumers) that I
haven't found an issue with it.

Still, on the topic of embedded FS'es, I stand by my original comment
that the majority of embedded applications have no need of LFNs. Thank
God, the vast majority of embedded projects are not Yet Another MP3
Player.

> years ago? 99% of the MP3 files I produce don't have tags. Simply
> because I'm too lazy to fill them in, and because file names work very well.

Ah, but they don't for me - I want to be able to sort on album,
artist, year at the very minimum.

> >>major nuisances such as "dir c:\*1*" showing "c:\Program Files" and
> >>"c:\Documents and Settings", which have a "1" in their short name.
>
> > That's a bug in the way CMD.EXE parses wildcards, though - not an
> > inherent FS bug.
>
> That bug, if you want to call it that, is in the FindFirstFile function,
> and is documented in the API description (e.g. page "Searching
> Filenames" in win32.hlp).

It's an API limitation which is worked around practically everywhere
else in Windows, and the absence of a workaround in CMD.EXE is I would
say a bug (or rather a lack of priority, since MS deprecates use of
the command-line).

It's not a naive idea, its just challenging. Of course there are issue
when porting anything. However you can design code to be portable, and mak
any porting easier for the end developer.

Can you explain why on a single core system why you think that disablin
interrupts won't guarantee atomic operations, and also explain why yo
think it is bad.

Working on BlackFIN, disabling interrupts means that the VDK Os schedule
simply cannot switch threads/processes because as with all OS's thi
requires a timer interrupt.

Obviously disabling interrupts is bad if done over to long a period o
time. It is sometimes necessary I believe, and if you fully understand whe
to do it and how then its ok. Essentially it should only be done over
very short period of time.

On a single-core system, if disabling interrupts prevents the OS from tas
switching, this should mean that all operations are atomic. If that is th
case, a simple mutex lock system should implementable?

I don't know the answers, I just want your opinions, and you
explanations.

James
[..]

Op Sat, 31 Jan 2009 19:09:27 +0100 schreef james.walmsley
<james>:
> I am creating an Open-Source thread-safe FAT file-system implementation
> called FullFAT. ([..]) (fullfat.googlecode.com)
>
> How can I guarantee a safe atomic operation.

Allow only one OS process to execute file system operations. No need for
semaphores or disabling of interrupts, just a suitable message passing
system. Replace the FS functions by stubs that communicate with the FS
process.

"larwe" <zwsdotcom> wrote in message
news:7d15
On Feb 1, 1:07 pm, Stefan Reuther <stefann> wrote:


>Apple isn't Chinese :)

......yet.

larwe wrote:
> On Feb 1, 1:07 pm, Stefan Reuther <stefann> wrote:
>>>Well, (a) the world DOES NOT need yet another MP3 player project,
>>
>>You mean, we should ignore all those millions of people wanting to buy
>>devices with MP3 ability and leave them to the Chinese? I'm glad my boss
>
> Apple isn't Chinese :)

As far as I know, Apple doesn't make music centres, nor DVD players or
TV sets (which often come with USB these days). And even if they did,
I'm sure, and would hope, that one or another company would find a
little competition interesting :)

> Still, on the topic of embedded FS'es, I stand by my original comment
> that the majority of embedded applications have no need of LFNs. Thank
> God, the vast majority of embedded projects are not Yet Another MP3
> Player.

If you consider the vast amount of industry electronics, then yes. A PBX
doesn't need long file names to be able to accept configuration updates
from a memory card. But consumer electronics?

Actually, LG Electronics even has (or wants?) a patent for a washing
machine with MP3 player. German news article:
<http://www.heise.de/newsticker/meldung/90317>
It was *not* published on April 1st.


Stefan