In article <IP208.92May11212855@puppe.ii.uib.no> magnus@hsr.no writes:
quoted text
>I may be chewing an old bone here, but is 28 characters in a file name
>really enough..? It's a lot better than what we have now, of course -
>but why not go for the 256 at once?

The reason I chose 30 (or 28) chars is that I don't want to move away
from the fixed-length directory structure for the first "non-minix" vfs
system I write: that way I can avoid some of the troubles, while still
getting a reasonable system.  Having a 256-char fixed-length directory
structure is a bit too wasteful even for my taste. 

Why fixed-length? It's partly because it's slightly easier (not that
it's that noticeable: I think the vfs routines will have no problem at
all with variable-sized names), but mostly because it can be gotten
almost for free with only minor tweaking of the current minix
vfs-sources.  Thus it will serve as an example of having different
filesystems at the same time, while not actually adding very much code
to the kernel. 

quoted text
>                                    Or does what you said imply that I
>can make a few simple changes (additions) in the source and build my
>own filesystem? I still would like 256 ch/filename to be a standard..

Yes, it should be pretty easy to change the sources to add a filesystem
of your own with any filename length (255 chars max due to an arbitrary
limit: I think that will be enough for everybody).  It will be a lot
easier when you have some examples, I think. 

Also, even if you made this change just on your own system, it isn't
visible on a user level at all, except for the fact that you can create
longer filenames of course.  This means that you can run any binaries
you want on the new filesystem, and as long as they have been compiled
with the new gcc-2.1 that supports readdir(), they will work on any
system, including your own specialized fs. 

                Linus