Luca Abeni wrote:
>>- the new NLS stuff is pracrically done and it is an optional module
> This is really good! So, will we finally able to remove all this stuff
> from the kernel?
Oh, yes! The NLS manager is a module to be loaded for things which needs
code page support.
Only one concern: the DPMI driver (actually the DOS API) expect strings
encoded in OEM code pages, but we have to use UTF-8 internally. This
makes no difference if you use ASCII, but is important since
applications may pass any text to the DOS API. So the DPMI driver would
depend on the NLS manager, and this is quite ugly. We would probably
need some fallback if the DPMI driver is loaded without the NLS manager.
>>- clean the devices stuff, and strip unnecessary things from the kernel
> Ok... Can you just summarize which things you are removing?
Basically, #include <dr-env.h> ;-)
More seriously, I'm converting the request function to a (more standard
and handly) variadic function. So I'm going to remove most of the
parameter structures of the old request function. Moreover I'm adding
structure of operations (like struct file_operations) for common
operations, as you once suggested.
>>- make the kernel independent from the fs manager...
>>- ...and modularize the fs manager so one can chose the preferred fs
>>manager variant (for hypotetical example, dos-style, multiuser, etc.)
> Uhhh... Not sure if this is really needed, but it seems cool ;-)
I agree... this is just an excuse to make the fs manager a module ;-)
Anyway, it could be useful, for example, to reduce the FD32 footprint if
a user needs, for example, a plain file system without advanced
features. Or simply to make FD32 behave any way you like.
>>- make all the new stuff more oriented towards the GNU libc rather than
>>- move the DOS interface to a DOS "emulation" driver, closely related to
>>the DPMI driver for the API; I suppose the two may be the same thing, so
>>I'd need Luca to clarify what he thinks should be removed from the DPMI
> Well... In my opinion, DPMI is the DOS interface. We used it as a base
> to define the "internal" kernel interface because it looked like a nice
> starting point, hence some of the fd32_* functions are very similar to
> the corresponding DPMI services.
> Now I do not think that having two separate DPMI and DOS drivers is a
> good idea...
I agree (this is what I thought when I wrote "I suppose the two may be
the same thing"). So this is my idea: we are focusing on DJGPP as our
reference compiler, and it basically uses the GNU C library; the GNU C
libary is *much* more well designed than the DOS API (someone may say
that is the DOS API that is poorly designed...); the DPMI interface was
indeed a good starting point, but it has several limitations if used as
internal interface, so we could just move it at a higher level, and let
it be just an interface, as planned.
I feel it is much easier to emulate the DOS API on top on a libc-like
interface than viceversa (the DJGPP fstat docet). For example, instead
of placing the brain damaged findfirst/findnext stuff inside the fs
manager, we could place this in the DPMI driver, and letting the fs
manager provide the classic open/readdir/close functions. We already did
this for fs drivers, I feel we can do this for the fs manager too.
But IIRC, you once told me that the current DPMI driver contains
something you'd prefer outside, and this is what I was asking. I fear it
could become like a garage...
> Anyway, I'd suggest you to begin to commit your stuff, so that we can
> have a better picture about what's going on... If you feel that your
> code is still unstable, or if it does not compile, you can just create a
> new branch for it. When everything will be stabilized, I can work on
> merging the various branches.
Unfortunately I have very little stuff to commit :-(
Anyway I'll let you know when I have something useful.