From: Tomasz W. <ma...@be...> - 2000-04-24 21:01:00
|
How portable KGI is ? Is only mechanism used to obtain hardware resources needed to be changed when porting KGI to other POSIX system, or is this very Linux-specific ? |
From: Steffen S. <s.s...@ph...> - 2000-04-25 06:11:09
|
Tomasz Wegrzanowski wrote: > How portable KGI is ? I have tried to keep it as portable as possible. > Is only mechanism used to obtain hardware resources > needed to be changed when porting KGI to other POSIX system, > or is this very Linux-specific ? I will split my answer according to the various KGI subsystems: 1) KGI environment (console management, boot display drivers, /dev/graphic special file mapper etc.) This is quite Linux specific in terms of the TTY driver and /dev/graphic special file driver interface used to actually link these driver into Linux. However, I tried to keep OS dependencies out of all KGI internal stuff where that seemed to make sense An exception is that it assumes a monolithic kernel design, which is that we assume we are running non-preemptive when executing this code. The boot display and input device drivers are i386 and PC architecture specific. They are just there to ge a machine running, until we have a file system and can get the real display drivers loaded. Thus porting KGI to another (Linux-)architecture will require implementation of proper boot drivers too. 2) KGI display drivers (in the drv/display directory, formerly referenced as driver/graphics) These drivers require only a working KGI environment, so once you have the environment ported, you should have all the drivers. Actually not even that, the drivers themselves only need the hardware resource allocation and handling to work properly. (e.g. as long as the stuff in http://kgi.sourceforge.net/source/kgi-0.9/kgi/include/kgi/io.h is supplied by the 'other POSIX OS' If you intend porting KGI to another OS, starting to look over system.h, io.h and creating <cpu-type>-compiler.h, <cpu-type>-types.h should make definitions of most KGI basic types and the basic I/O operations operational. Done this the drivers should already compile. (Re-)implementing the OS environment will take some more work, depending on how much the 'other POSIX OS' will differ from Linux. I hope that answers your question, if not, don't hesiate to ask further questions. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
From: Tomasz W. <ma...@be...> - 2000-04-26 01:53:57
|
On Tue, Apr 25, 2000 at 08:02:51AM +0200, Steffen Seeger wrote: > > 1) KGI environment (console management, boot display drivers, > /dev/graphic special file mapper etc.) > > This is quite Linux specific in terms of the TTY driver > and /dev/graphic special file driver interface used to > actually link these driver into Linux. > However, I tried to keep OS dependencies out of > all KGI internal stuff where that seemed to make sense > An exception is that it assumes a monolithic > kernel design, which is that we assume we are running > non-preemptive when executing this code. Does it mean 1) it has to be run in kernel space 2) it may be run in kernel space or as real-time process 3) only some marked parts of code must be run non-preemptive > The boot display and input device drivers are i386 and > PC architecture specific. They are just there to ge a machine > running, until we have a file system and can get the real > display drivers loaded. Thus porting KGI to another > (Linux-)architecture will require implementation of proper > boot drivers too. Is it possible to leave original boot driver and run KGI later, when system is in more usual state ? > 2) KGI display drivers (in the drv/display directory, formerly > referenced as driver/graphics) > > These drivers require only a working KGI environment, so > once you have the environment ported, you should have all the > drivers. Actually not even that, the drivers themselves only > need the hardware resource allocation and handling to work > properly. (e.g. as long as the stuff in > http://kgi.sourceforge.net/source/kgi-0.9/kgi/include/kgi/io.h > is supplied by the 'other POSIX OS' > > If you intend porting KGI to another OS, starting to look over > system.h, io.h and creating <cpu-type>-compiler.h, <cpu-type>-types.h > should make definitions of most KGI basic types and the basic > I/O operations operational. Done this the drivers should already > compile. (Re-)implementing the OS environment will take some more work, > depending on how much the 'other POSIX OS' will differ from Linux. i386-* should work, I'm on i386 system.h and io.h won't work w/o modifications > I hope that answers your question, if not, don't hesiate to ask further > questions. and before I will try to do any real work : why does make make so many warnings (about overwriting commands) ? |
From: Steffen S. <s.s...@ph...> - 2000-04-26 12:33:23
|
Tomasz Wegrzanowski wrote: > On Tue, Apr 25, 2000 at 08:02:51AM +0200, Steffen Seeger wrote: > > > > 1) KGI environment (console management, boot display drivers, > > /dev/graphic special file mapper etc.) > > > > This is quite Linux specific in terms of the TTY driver > > and /dev/graphic special file driver interface used to > > actually link these driver into Linux. > > However, I tried to keep OS dependencies out of > > all KGI internal stuff where that seemed to make sense > > An exception is that it assumes a monolithic > > kernel design, which is that we assume we are running > > non-preemptive when executing this code. > > Does it mean > 1) it has to be run in kernel space No. All drivers require only the KGI I/O operations, that is resource management and in/out operations. So the drivers need only sufficient permissions to access the regions registered before. IRQ handling need not be implemented, but this may result in limited capabilities of the drivers (e.g. acceleration features may not be available). The mappers (console and /dev/graphic special file driver) require a communication channel to the drivers and need to interface the virtual file system. For Linux, most easy way is to put this in kernel space, but it need not. The KGI management code (which does driver registration, command and event dispatchign) links mappers and drivers together. This is implemented as function calls, but in theory you should be able to use messages too. > 2) it may be run in kernel space or as real-time process Yes. The drivers are written such that you may run them in either kernel space or as a real-time process. Though I have not yet found a reasonable definition what 'real-time' means here. > 3) only some marked parts of code must be run non-preemptive Yes. The drivers coded with the following assumptions in mind: 1) Each driver is single-threaded. That is, the environment has to make sure previous calls to display driver functions (provided through the kgi_display_t struct have completed before further calls are made. The current environment implementation does not care about this, but adding SMP safety should be easy every driver entry is guarded with appropriate locks. 2) Driver routines that require extensive I/O (setting display mode, initializing and de-initializing the hardware) should not be interrupted by other drivers accessing hardware on the same bus. Some hardware is sensitive to this, some isn't. In general, mode setting operations are kept as short as possible, and are required only once when initializing a mode. > > The boot display and input device drivers are i386 and > > PC architecture specific. They are just there to ge a machine > > running, until we have a file system and can get the real > > display drivers loaded. Thus porting KGI to another > > (Linux-)architecture will require implementation of proper > > boot drivers too. > > Is it possible to leave original boot driver and run KGI later, > when system is in more usual state ? Yes, but the KGI environment needs to be available before you start and other drivers and KGI drivers -- once registered -- are the only drivers thouching a certain piece of hardware unless they granted access to applications. The boot driver allows console output as early as possible. As soon as the KGI environment is initialized, real (fully featured) display drivers may be loaded. Just enable the KGI splash screen in the Linux implementation and disable the calls to i386_dpy_init(), then you will see the boot display driver in action. Once the KGI environment is available, you can load display drivers on top of others, either overriding or modifying certain functions of the underlying display driver. However, so far only an 'overriding all driver functions' framework is implemented (drv/display/system/Linux/kgi-0.9.c). > > 2) KGI display drivers (in the drv/display directory, formerly > > referenced as driver/graphics) > > > > These drivers require only a working KGI environment, so > > once you have the environment ported, you should have all the > > drivers. Actually not even that, the drivers themselves only > > need the hardware resource allocation and handling to work > > properly. (e.g. as long as the stuff in > > http://kgi.sourceforge.net/source/kgi-0.9/kgi/include/kgi/io.h > > is supplied by the 'other POSIX OS' > > > > If you intend porting KGI to another OS, starting to look over > > system.h, io.h and creating <cpu-type>-compiler.h, <cpu-type>-types.h > > should make definitions of most KGI basic types and the basic > > I/O operations operational. Done this the drivers should already > > compile. (Re-)implementing the OS environment will take some more work, > > depending on how much the 'other POSIX OS' will differ from Linux. > > i386-* should work, I'm on i386 > system.h and io.h won't work w/o modifications If you are using the GNU C compiler. > > I hope that answers your question, if not, don't hesiate to ask further > > questions. > > and before I will try to do any real work : > why does make make so many warnings (about overwriting commands) ? Could you send me an log that shows the messages you are getting, please? I have not tested all possible configurations, so may be you spotted a bug. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
From: Tomasz W. <ma...@be...> - 2000-04-26 21:57:40
|
On Wed, Apr 26, 2000 at 02:25:06PM +0200, Steffen Seeger wrote: > If you are using the GNU C compiler. Are there any non-GNU non-toy compilers for Unices ? (I have very little experience with non-free Unices) > > and before I will try to do any real work : > > why does make make so many warnings (about overwriting commands) ? > > Could you send me an log that shows the messages you are getting, please? > I have not tested all possible configurations, so may be you spotted a bug. Here is the start of make's output ( system is Debian GNU/Linux on i386; GNU make 3.78.1 ) /root/kgi-0.9/Makefile:4: warning: overriding commands for target `config' /root/kgi-0.9/Makefile:4: warning: ignoring old commands for target `config' /root/kgi-0.9/Makefile:7: warning: overriding commands for target `snapshot' /root/kgi-0.9/Makefile:7: warning: ignoring old commands for target `snapshot' make[1]: Entering directory `/root/kgi-0.9/app' make[2]: Entering directory `/root/kgi-0.9/app/X11' /root/kgi-0.9/app/X11/Makefile:6: warning: overriding commands for target `default.exit' /root/kgi-0.9/app/X11/Makefile:6: warning: ignoring old commands for target `default.exit' /root/kgi-0.9/app/X11/Makefile:9: warning: overriding commands for target `clean.exit' /root/kgi-0.9/app/X11/Makefile:9: warning: ignoring old commands for target `clean.exit' /root/kgi-0.9/app/X11/Makefile:12: warning: overriding commands for target `distclean.exit' /root/kgi-0.9/app/X11/Makefile:12: warning: ignoring old commands for target `distclean.exit' /root/kgi-0.9/app/X11/Makefile:23: warning: overriding commands for target `diffs' /root/kgi-0.9/app/X11/Makefile:23: warning: ignoring old commands for target `diffs' (cd xc; make World 2>&1 | tee ../make-World.log) make[3]: Entering directory `/root/kgi-0.9/app/X11/xc' make[3]: *** No rule to make target `World'. Stop. make[3]: Leaving directory `/root/kgi-0.9/app/X11/xc' make[2]: Leaving directory `/root/kgi-0.9/app/X11' make[1]: Leaving directory `/root/kgi-0.9/app' make[1]: Entering directory `/root/kgi-0.9/drv' make[2]: Entering directory `/root/kgi-0.9/drv/display' /root/kgi-0.9/drv/display/Makefile:8: warning: overriding commands for target `modules/ELSA/WinnerOffice2000.o' /root/kgi-0.9/drv/display/Makefile:8: warning: ignoring old commands for target `modules/ELSA/WinnerOffice2000.o' /root/kgi-0.9/drv/display/Makefile:13: warning: overriding commands for target `distclean.exit' /root/kgi-0.9/drv/display/Makefile:13: warning: ignoring old commands for target `distclean.exit' make[3]: Entering directory `/root/kgi-0.9/drv/display/board' /root/kgi-0.9/drv/display/board/Makefile:2: warning: overriding commands for target `default.entry' /root/kgi-0.9/drv/display/board/Makefile:2: warning: ignoring old commands for target `default.entry' /root/kgi-0.9/drv/display/board/Makefile:5: warning: overriding commands for target `default.exit' /root/kgi-0.9/drv/display/board/Makefile:5: warning: ignoring old commands for target `default.exit' /root/kgi-0.9/drv/display/board/Makefile:8: warning: overriding commands for target `distclean.exit' /root/kgi-0.9/drv/display/board/Makefile:8: warning: ignoring old commands for target `distclean.exit' ... |
From: Steffen S. <s.s...@ph...> - 2000-05-01 14:25:25
|
Tomasz Wegrzanowski wrote: > > On Wed, Apr 26, 2000 at 02:25:06PM +0200, Steffen Seeger wrote: > > > If you are using the GNU C compiler. > > Are there any non-GNU non-toy compilers for Unices ? > (I have very little experience with non-free Unices) E.G. there are the Portland Group compilers, which are supposed to produce better optimized code under some circumstances. But they are not free. > > > and before I will try to do any real work : > > > why does make make so many warnings (about overwriting commands) ? > > > > Could you send me an log that shows the messages you are getting, please? > > I have not tested all possible configurations, so may be you spotted a bug. > > Here is the start of make's output ( system is Debian GNU/Linux on i386; GNU make 3.78.1 ) > > /root/kgi-0.9/Makefile:4: warning: overriding commands for target `config' > /root/kgi-0.9/Makefile:4: warning: ignoring old commands for target `config' > /root/kgi-0.9/Makefile:7: warning: overriding commands for target `snapshot' > /root/kgi-0.9/Makefile:7: warning: ignoring old commands for target `snapshot' > make[1]: Entering directory `/root/kgi-0.9/app' I have not been able to reproduce these messages using GNU Make 3.77, 3.78.1 and 3.79 on a RedHat-6.0 system. All work as intended and give no warnings about overriding commands. Are there any differences to the standard gmake (e.g. in configuration) between the make-3.78.1.tar.gz and that from Debian? Could you perhaps give me more details what source (CVS or which snapshot) you are using and how you configured it? > (cd xc; make World 2>&1 | tee ../make-World.log) > make[3]: Entering directory `/root/kgi-0.9/app/X11/xc' > make[3]: *** No rule to make target `World'. Stop. This addresses a real bug fixed in my current tree. I will commit my changes on Tuesday. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |