On Saturday 31 October 2009 02:35:42 Sean Moss-Pultz wrote: > On Sat, Oct 31, 2009 at 3:46 AM, Doug Jones <dj...@frombob.to> wrote: > > (1) Has OpenMoko made the policy decision that filenames will be limited > > to 8.3? > > We're using FAT.
I have a usable grasp of how FAT works, so I figured this would be the answer while reading this thread, and thought I'd reply with an explanation even before I saw your reply. It's not just policy, there are technical reasons. While I suppose it's really enough to accept that this is how it is, I guess people with less of a grasp on how FAT works might need an explanation to really understand why this is the only sensible choice, so here goes: The FAT filesystem inherently supports up to 8.3 filenames, and nothing more. This is a limitation of the on-disk format used for directories (including the root directory). Long file name (LFN) support has been implemented on top of this (aka VFAT) in some systems, but it is really a hack: it adds extra directory entries that are (iirc) marked as being deleted files, and then uses the rest of the data (both filename and other fields, like size) for those entries to contain characters representing the long filename for the following directory entry (the real file). Thus, implementing this is a bit complex and hacky. This is why DOS (and the DOS mode of W9x) doesn't see the long file names (just foobar~1.ext), and might destroy the LFN if you do certain things with the files (such as moving to another dir) - they were made before LFNs existed. Besides, even with just 8.3, that's 11 bytes that can be chosen pretty much arbitrarily (only a few values you can't use); for most purposes you don't need even that, and can put conventions into place (such as using a specific .ext for specific file types). Personally, I see no reason why the wikireader should need more than 8.3 filenames, at least for the kernel to know what app to start, or the reader app to find its data files. > > (2) How complicated will it be to implement subdirectory support? > > Not a problem. We're going to do something like this when we support > more languages. That certainly seems like both the easiest and most sensible approach. > > Note that only one subdirectory level is really needed to implement what > > has already been suggested. This is kind of interesting in a way. The first DOS versions (that supported directories at all) only supported one level. :) > > We could adopt a brain-swap approach: After bootup, the user selects > > one wiki and then the app switches to the selected subdirectory and > > considers that to be the root until the next cold boot. All 81 files <snip> > > kernel.elf. Only the initial wiki selection app (we would have to write > > one) would have to understand subdirectories, and only to one level deep. > > Yeah that should work. I thought of the same, and afaik there's just one small gotcha (not really a problem though): subdirectories are not quite the same on-disk as the root directory. The format of the data in the directories is the same, sure. But subdirectories are stored the same way files are - in a chain of clusters - while the root directory is a specific area on the disk, determined at FS creation time. This is why the root directory has a limited number of files it can hold, while subdirectories don't. So, the code reading the directory entries from the disk still has to know if it's reading the root dir or a subdirectory, to know where on the disk to load the entries from. The code parsing those entries can be the same though. One way to simplify this could be to *always* keep apps such as the wikireader in a subdirectory, never in the root directory, as then only the app selector needs to know how to read the root dir. Of course, if the filesystem reading/parsing code is provided by the kernel, as a service to the programs, it could take care of this (rather small) difference under the hood, without each app having to deal with it on its own - that seems much more sensible to me, since it needs to know how to read FAT anyway. That could also open up another intriguing possibility... Copying the app selector into a subdir that has subdirs of its own. From the POV of any app that doesn't understand directories, it doesn't really matter how deep it is, and even if it does understand them, it still doesn't matter as long as the current directory is considered the root and the .. directory is ignored. Then, if the selector was implemented so that it could switch root to the .. directory and (re)start that app, you could even move up again in the tree... Well, this all assumes the "root" subdir selection is done by keeping the cluster number or some such (as opposed to keeping the path by name). -- Frode Austvik _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
