Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Hurd Traffic #40 For 22 Mar 2000

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
 
-- Linus Torvalds, 1991

Table Of Contents

Mailing List Stats For This Week

We looked at 87 posts in 272K.

There were 27 different contributors. 14 posted more than once. 9 posted last week too.

The top posters of the week were:

 

1. Virtual Terminals; 'lynx' And 'vi' Crashes; Hurd Documentation
13 Mar 2000 - 15 Mar 2000 (11 posts) Archive Link: "vts?"
Topics: Bootloaders
People: Neal H WalfieldMarcus BrinkmannBrad MarksTomasz Wegrzanowski

Someone had a few questions. First, they asked if it was possible to have more than one virtual terminal under the Hurd. Tomasz Wegrzanowski and Marcus Brinkmann both suggested the 'screen' program as a decent alternative, since actual virtual terminals were not yet available.

The original poster also noticed that 'vi' and 'lynx' would crash often, in fact, they would hardly stay up at all. Marcus uttered an exclamation, and ponited out that 'lynx' was incompatible with the current 'libz', and would need to be recompiled at least. He asked which flavor of 'vi' the original poster was using, and Neal H Walfield replied, "I am guessing that he is using nvi. nvi will often freeze for no apparent reason. The work around would be to either: kill vi and start editing where you left off (via vi -r) OR use vim."

The original poster also asked how to help Hurd development, even without being a particuarly great programmer. Marcus replied, "Guess what, you are already helping, ;)" , and Tomasz suggested writing some documentation. Brad Marks replied, "I'd put in some time for documentation if I knew where to start.. i.e. what needs done most urgently, who do I submit it to, does it need to be in any specific format (where it might end up could be good to know if I'm going to be putting html links on it). A documentation task list could be a good idea to co-ordinate people like us." Tomasz replied:

My proposals :

  • 1 central page with *all* Hurd and Mach papers ( mirrored in Europe )
  • some common errors list, with `default pager errors', GRUB fails etc.
  • list of all GNU/Hurd CD sellers, as soon as someone will sell them
  • pointers to all Hurd-related projects
  • translators writers' manual, especially about writing them in perl

Brad replied:

Sounds good but this hasn't materialized into anything and my plans to help out with this have started to slide the other way.

What needs to be done, and who should I contact about it? I don't want to start documenting on my own just to find out that someone else is doing the same thing or already has.

Sorry to keep this thread alive but I don't think doing so will be too counterproductive..

There was no reply.

 

2. Graphics Under The Hurd
13 Mar 2000 - 14 Mar 2000 (5 posts) Archive Link: "Graphics on Hurd"
People: Tomasz WegrzanowskiMarcus Brinkmann

Tomasz Wegrzanowski asked if it was possible to do graphics under the Hurd, and Marcus Brinkmann replied that it would be extremely difficult, and would involve talking directly with GNU mach. Tomasz asked if anyone had succeeded in actually switching to graphics mode and drawing some pixels, but there was no reply.

 

3. Package Porting Procedures, Successes, And Future Attempts
16 Mar 2000 - 17 Mar 2000 (4 posts) Archive Link: "Software ported to Hurd"
People: Tomasz WegrzanowskiMarcus Brinkmann

Tomasz Wegrzanowski felt that very few packages had been successfully ported to the Hurd, and asked if this was because of actual porting problems, or if the packages were simply not uploaded to the FTP server. If it was due to porting problems, then he asked where he should report ported packages; while if it was due to FTP unavailability, he asked where he could find a list of ported packages.

Marcus Brinkmann felt that the number of available packages was not that small, and added that he was currently working on an autobuilder, which would try to do an automatic compilation of everything; though it wasn't ready yet. He went on to say that the debian-hurd mailing list was the proper place to report on ported packages, and that the FTP archive was indeed uptodate with all successfully ported packages.

Tomasz announced that he'd successfully ported Midnight Commander; he'd done some work on porting 'w3w', but still had a few problems to solve; and 'dictd' was next on his list, although he hadn't done any actual work on it yet. Marcus replied that he was looking forward to 'dictd'.

 

4. Porting 'apt'
17 Mar 2000 (4 posts) Archive Link: "mmap ?"
Topics: Apt
People: Brent Fulgham

Kimmo K. I. Surakka was trying to port 'apt' to the Hurd, but couldn't find the definition of the MS_SYNC symstant. Brent Fulgham replied:

I have spent a little bit of time myself playing with this. The problems run a bit deeper than you can see at first. While the MS_SYNCH issue is annoying, it is not critical. Just comment those lines out.

The problem occurs later in the program, when it tries to establish a socket connection to the server with the APT data. For some reason, I have not been able to get it to successfully negotiate this transaction.

The newer HURD may have better support for the SOCKOPT features than I had when I last played with it.

 

5. Hurd On The Alpha
19 Mar 2000 (6 posts) Archive Link: "Hurd and the Alpha"
People: Neal H WalfieldRoland McGrathDavid Andrews

Greg Meno wanted to port the Hurd to the Alpha processor, and asked what would be involved. Neal H Walfield gave a pointer to the Hurd, Mach, and Grub sources, and replied, "Currently, the hurd only runs on the i386 family of processors. If you would like to start a porting effort to the alpha, I would suggest that you start port gnu mach. If you get that running, then you need a boot loader. Again, grub is only for the i386 (at the moment, plans are in progress for another release and then portability fixes). Finally, you will need to port the rest of the hurd. This should be (relatively) easy. The hurd has been written with portability in mind, however, I am sure that there are a few 32isms present." Also independantly replying to Greg, Roland McGrath explained:

The component you need to worry about first is the microkernel, which will be a substantial task by itself before you worry about the (relatively much easier) details of porting the Hurd. There once was a port of CMU Mach 3.0 to the Alpha, and if you can track that down on the net it should not be all that bad to merge its Alpha support into GNU Mach (which in its core code is really not much changed from CMU Mach 3.0). I imagine that a whole lot more of the Alpha hardware in the world is supported by current Linux and NetBSD versions than was supported by the Mach ports to be found (which were done some years back and as far as I know not updated in a long time).

Another approach would be port OSKit-Mach to the Alpha, starting by porting the OSKit to the Alpha. If you want to take an oskit-based approach, then you should be talking on oskit-users@cs.utah.edu; fortunately, there was a recent posting there about someone else already planning an Alpha port of the OSKit, which would give you a decent leg up on porting Mach.

David Andrews pointed out that there had been some talk of replacing mach (see Issue #13, Section #5  (19 Aug 1999: The Future Of Mach) and Issue #21, Section #2  (15 Oct 1999: Porting The Hurd To Alphas) ), and that the consensus had been to just get the Hurd working, before thinking about switching microkernels. He put in, "I guess that's probably sound advice -- if we're only talking about a single platform (x86). But it seems to me that if Greg wants an Alpha Hurd, and he has the wherewithal to undertake this, then it would be foolish to port Mach in light of our nascent desire to replace it." Scott Fenton replied briefly that if there was going to be a port of mach to the Alpha, it might be the right time to move some more mach functionality into userspace. In particular, he felt that hardware support could be moved into a server. There was no reply to this, but Roland also replied to David regarding the porting issues:

The work involved in porting the microkernel to a new platform is not really very Mach-specific at all, and it is likely that any such work done would provide source code that could be reused in a different microkernel as well. If the approach is to port the OSKit and OSKit-Mach, that builds in even more reuse potential from the start.

The basic important fact here is that the parts of a microkernel that deal intimately with the hardware tend to be much the same for different microkernels on the same hardware, and the parts that differ greatly between different microkernels tend not to be parts that are innately machine-dependent. Indeed, the hardware-related code in microkernels is most often not deeply different from the hardware-related code in monolithic kernels. What makes reuse difficult is that the code hardware support code in monolithic kernels tends not to be very abstract or modular; that is, it is not modular with respect to different basic operating principles of a kernel, though it may be modular with respect to different hardware platforms. The device driver pieces of monolithic kernel code do tend to be more modular and use more abstract interfaces, which is why Mach and OSKit do in fact reuse the device drivers from Linux.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.