I'm planning out how to port Minix to L4 and I can't find any of the hearders.
http://tudos.de/l4env/doc/html/bid-tut/node2.html
I have CVS'd just about everything on your downloads page yet ./l4/include, ./l4/lib and ./l4/bin do not exist.
I feel that many of the choices regarding the layout of the source code and the usage of the more sophisticated tools only serve to obfuscate the system to new users. =(
On Tue Jul 18, 2006 at 15:26:34 -0500, Alan Grimes wrote:
I'm planning out how to port Minix to L4 and I can't find any of the hearders.
http://tudos.de/l4env/doc/html/bid-tut/node2.html
I have CVS'd just about everything on your downloads page yet ./l4/include, ./l4/lib and ./l4/bin do not exist.
Those directories are created in the object directory when you build the tree. They are in the packages initially and will be linked to the mentioned directories during the build.
I feel that many of the choices regarding the layout of the source code and the usage of the more sophisticated tools only serve to obfuscate the system to new users. =(
We are not obfuscating the system on purpose to make the life of anyone harder as it already is. But you won't find anyone saying that our documentation is an excellent example of documentation either. We're trying to do something about this but won't promise anything...
Adam
Adam Lackorzynski wrote:
I'm planning out how to port Minix to L4 and I can't find any of the hearders.
I have CVS'd just about everything on your downloads page yet ./l4/include, ./l4/lib and ./l4/bin do not exist.
Those directories are created in the object directory when you build the tree. They are in the packages initially and will be linked to the mentioned directories during the build.
I had suspected as much, it just wasn't documented that way.
My hope was to figure out what to do with the source code before breaking it.
I feel that many of the choices regarding the layout of the source code and the usage of the more sophisticated tools only serve to obfuscate the system to new users. =(
We are not obfuscating the system on purpose to make the life of anyone harder as it already is. But you won't find anyone saying that our documentation is an excellent example of documentation either. We're trying to do something about this but won't promise anything...
There's a great deal to be said against the design choices above.
1. Creating include directories in this kind of automated fassion obfuscates where the relevant files are. As a counterexample, the Minix source tree placess all PUBLIC header files in "./src/include" while keeping PRIVATE header files in "./src/kernel". It is hard to find fault with Minix's design choices because it is trivial to find exactly which headers your driver needs and know which ones it _SHOULD_ be using.
2. the "pkg" directory, possibly overcrowded on my system because I was essentially grabbing stuff at random, is far too flat for its own good.
Packages such as "qt" seem to be userspace packages ?? DOES L4 ACTUALLY HAVE A SUPPORTED GRAPHICS SYSTEM ??, and should not be lumped in with sigma0, rather they should be distributed in a completely indepandant source tree!
As a counterexample, Minix divides its sources into "commands", "drivers", "Servers", and "Lib". This organization is indispensible to someone trying to learn the system.
As it is, I'm faced with around 120 paths and no map! =(
3. Libraries and headers from the varrious packages should not be mixed except in the installed OS. Necessary headers should be -I'd into the build.
4. Automake, though it is a nightmare, actually does seem to help things on the user side. Since my Minix installation already works much much better than my Linux installation ever did, I'd like to be able to try to build L4 on it. =P -- Okay, not very realistic...
Minix has both its own version of make and Gmake.
In general, Minix is a very well laid-out system. I'd highly reccomend you look at how they laid out the tree and build system; But don't try to make L4 as cripled as Minix currently is!!! =P Users can't even use simple IPC on Minix!!! =((( -- hence my renewed interest in L4.
Cheers,
thanks for your advices, we will propably consider some of them during the design of successors to our current research OS.
For graphical user interface solutions from our group, please, have a look at http://demo.tudos.org/ and http://os.inf.tu-dresden.de/dope/.
Regards
For graphical user interface solutions from our group, please, have a look at http://demo.tudos.org/ and http://os.inf.tu-dresden.de/dope/.
I just ran your demo disk on my Athlon 800, a 6 year old machine, and OH MY GOD! It ran amazingly smooth. It had no trouble at all showing all the graphics demos at once and the quake game was smooth as silk. -- though quite challenging! =P
I've been trying to test out my own ideas about how to design an Operating system since I finalized the design in 2001. Jochen's writings about L4 were a major influence on my thinking.
I have had relatively poor luck with L4. I only learned receiently how modules can be loaded by GRUB. Previously, I thought they were linked with the binary. I've only been able to play with the pre-made demo disks.
With the new release of Minix, I had hoped to be able to rig up a server which would provide an API over IPC that would offer some of the features of my OS. -- without having to start from scratch... Minix, to my horror, reserves its microkernel features for it's pre-registered servers but then restricts userspace processes to the, by all rights, obsolete Unix API. =(
Looking for a quick fix, I thought it'd be comparatively easy to use L4 in place of the minix kernel where I'd be able to take advantage of the relatively mature microkernel unix implementation and also be able to use IPC.
So I went back to your fine project and tried, once again, to figure out how your source code is laid out... My thinking now is that I need to save up for air fare over to Germany and get a week's worth of training on this codebase...
I think a few of us might be interested in such an opportunity (for training :-)
On Wednesday 19 July 2006 13:47, Alan Grimes wrote:
For graphical user interface solutions from our group, please, have a look at http://demo.tudos.org/ and http://os.inf.tu-dresden.de/dope/.
I just ran your demo disk on my Athlon 800, a 6 year old machine, and OH MY GOD! It ran amazingly smooth. It had no trouble at all showing all the graphics demos at once and the quake game was smooth as silk. -- though quite challenging! =P
I've been trying to test out my own ideas about how to design an Operating system since I finalized the design in 2001. Jochen's writings about L4 were a major influence on my thinking.
I have had relatively poor luck with L4. I only learned receiently how modules can be loaded by GRUB. Previously, I thought they were linked with the binary. I've only been able to play with the pre-made demo disks.
With the new release of Minix, I had hoped to be able to rig up a server which would provide an API over IPC that would offer some of the features of my OS. -- without having to start from scratch... Minix, to my horror, reserves its microkernel features for it's pre-registered servers but then restricts userspace processes to the, by all rights, obsolete Unix API. =(
Looking for a quick fix, I thought it'd be comparatively easy to use L4 in place of the minix kernel where I'd be able to take advantage of the relatively mature microkernel unix implementation and also be able to use IPC.
So I went back to your fine project and tried, once again, to figure out how your source code is laid out... My thinking now is that I need to save up for air fare over to Germany and get a week's worth of training on this codebase...
So I went back to your fine project and tried, once again, to figure out how your source code is laid out... My thinking now is that I need to save up for air fare over to Germany and get a week's worth of training on this codebase...
Another possibility could be to take a look at some of the courseware written by the folks in Dresden for their courses. One can learn a lot about the codebase from the comfort of home. I'm currently doing this on my own in my spare time with the hope of doing something L4 related in the future here at UTEP (University of Texas at El Paso).
-Ryan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Alan,
Alan Grimes wrote on 19.07.2006 04:11 this:
There's a great deal to be said against the design choices above.
Then let me make a point for those design choices.
- Creating include directories in this kind of automated fassion
obfuscates where the relevant files are. As a counterexample, the Minix source tree placess all PUBLIC header files in "./src/include" while keeping PRIVATE header files in "./src/kernel". It is hard to find fault with Minix's design choices because it is trivial to find exactly which headers your driver needs and know which ones it _SHOULD_ be using.
As we see each "package" as a own piece of software, each has a PUBLIC header file directory, for example, l4/pkg/dm_phys/include and PRIVATE header files do appear either in the source directory or in private include directories, for example, l4/pkg/dm_phys/server/include.
- the "pkg" directory, possibly overcrowded on my system because I was
essentially grabbing stuff at random, is far too flat for its own good.
You might be right about that. It just grew and grew and grew and with cvs as repository it's just a pain in the ass to restructure the directory layout.
As a counterexample, Minix divides its sources into "commands", "drivers", "Servers", and "Lib". This organization is indispensible to someone trying to learn the system.
Most of the packages provided are services, which consist of a server running in its own address space (so you might want to place that into "Servers") and a client-library (which you probably would put into "Lib"). We also have server that are different implementations of the same interface, so you would probably have to have directories "Interfaces" and "Server- or Internal-libs" as well. Now the writer of one piece of software would have to maintain sources in three to five different directories. That's why we decided to group the source of one piece of software into one package.
- Libraries and headers from the varrious packages should not be mixed
except in the installed OS. Necessary headers should be -I'd into the build.
Let's say you have a types.h in package foo and a types.h in package bar. How do you differentiate them if you just -I their include paths. Now that's where the separate include path comes into play. Our make magic installs the headers of each package into include/l4/<package name>/. So foo/types.h and bar/types.h can be distinguished using the path in the #include statement. Otherwise we would have to either call them foo_types.h or bar_types.h or create subdirs in each package's include path. (Now explain that part to a novice ;) ).
- Automake, though it is a nightmare, actually does seem to help things
on the user side. Since my Minix installation already works much much better than my Linux installation ever did, I'd like to be able to try to build L4 on it. =P -- Okay, not very realistic...
You might be right about using automake. If you volounteer to migrate our build system to using automake we will give you reasonable credit on the webpages and READMEs.
In general, Minix is a very well laid-out system. I'd highly reccomend you look at how they laid out the tree and build system; But don't try to make L4 as cripled as Minix currently is!!! =P Users can't even use simple IPC on Minix!!! =((( -- hence my renewed interest in L4.
We try! I like to use one of my favourite open source citations here: "Hey, it's open source. If you like to see it improved, go ahead!" (No offense!)
Regards, Ron. - -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
On Wednesday 19 July 2006 10:35, Ronald Aigner wrote:
You might be right about that. It just grew and grew and grew and with cvs as repository it's just a pain in the ass to restructure the directory layout.
Why not to switch over to SVN? :)
We try! I like to use one of my favourite open source citations here: "Hey, it's open source. If you like to see it improved, go ahead!" (No offense!)
There are other problems, like.. who decides the goals of the project, and makes the planning?
As I see it, this is a project of an OS group at an University, the project itself is a kind of experiment, and it's there to fit the needs of the researchers in that group. It's very likely that, if the project gets broadly used outside the University, at some point conflicts would arise about changes needed to achieve this or that, that renders the project unusable for research (or the other way around). What would happen then?
I don't know if these issues have already been discussed inside the OS group, I would appreciate if somebody could explain that, as well as point me to some document about the plans for the near future. The webpages don't make almost reference to TUD:OS yet, they talk about DROPS only...
Greetings.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Manuel,
Manuel A. Fernandez Montecelo wrote on 19.07.2006 23:07 this:
On Wednesday 19 July 2006 10:35, Ronald Aigner wrote:
You might be right about that. It just grew and grew and grew and with cvs as repository it's just a pain in the ass to restructure the directory layout.
Why not to switch over to SVN? :)
We are in the progress of doing so :) Maybe after that we will find a better layout for our source (maybe close to that of Minix) and make some 'svn move's then :)
Greetings, Ron.
PS: Also some good resources can be found at the L4 headquarters http://l4hq.org/
- -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Alan Grimes -
Christian Helmuth -
Manuel A. Fernandez Montecelo -
Michael J. Emswiler -
Ronald Aigner -
Ryan C. Spring