Subject: Linux-Development Digest #567 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Sun, 20 Mar 94 16:13:08 EST Linux-Development Digest #567, Volume #1 Sun, 20 Mar 94 16:13:08 EST Contents: How to write a device driver (root@jaxnet.com) Libc 4.5.24 & catclose() in nl_types.h (Byron Faber) Re: How to write a device driver (Chris Hafey) Re: blank_screen patch for Laptops (Questions) (Orest Zborowski) Re: Linux for Sun4 (Orest Zborowski) Which finger? (Karl Buck) dialog-0.3 patches for 8 bit environment (Nickolay Saukh) Re: Real-Time Linux and a/d device drivers (Warner Losh) Re: Linux for Sun4 (Anatoly N Ivasyuk) Re: SIGIO with Non-Blocking sockets? (Robert Sanders) Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS] (Kevin Brown) Re: Real-Time Linux and a/d device drivers (Kevin Brown) Re: Linux for Sun4 (Dominik Kubla) ---------------------------------------------------------------------------- From: root@jaxnet.com Subject: How to write a device driver Date: Sat, 19 Mar 1994 11:18:36 GMT I am an experienced applications programmer and I would like to learn how to write a device driver for Linux. Can anyone recommend a book that will help me get started. I have written a serial device driver for DOS so I think I am up to the challenge but I need a book to learn from. A book on operating systems (how to build) would also be great. -- Karl Renaut root@jaxnet.com ------------------------------ From: btf57346@uxa.cso.uiuc.edu (Byron Faber) Subject: Libc 4.5.24 & catclose() in nl_types.h Date: 20 Mar 1994 07:32:20 GMT I'm compiling tcl/tk & tclX In one of the files I get the following contradictory information: tclX (some file) does if((catclose(variable) < 0) . . . . . yet catclose is defined as extern void in /usr/include/nl_typles. Could somebody tell me what the 0 does? I assume its an error, but how is the error handled now? (variable = void?) Sorry I don't have source for libc 4.5.24 on me. Thanks, Byron Faber -- `Playing this disk at loud volume may permanently damage your speakers or other sound components.' -LFO b-faber@uiuc.edu ------------------------------ From: chafey@ecst.csuchico.edu (Chris Hafey) Subject: Re: How to write a device driver Date: 20 Mar 1994 09:48:55 GMT In article , wrote: >I am an experienced applications programmer and I would like to learn how to >write a device driver for Linux. Can anyone recommend a book that will >help me get started. I have written a serial device driver for DOS so I >think I am up to the challenge but I need a book to learn from. A book >on operating systems (how to build) would also be great. An ok book which I have used is: Writing a Unix Device Driver Janet I Egan & Thomas J Teixeira Publisher: John Wiley & Sons (wiley) ISBN 0-471-53574-5 But over all other things, you really need to dig into the kernel and see how things are being done. Find a driver that does something close to what you want to do and copy it. The linux kernel hackers guide is also very good at describing what is going on inside the kernel. You can get it on sunsite.unc.edu or tsx-11.mit.edu. Look for LDP or linux documentation project. Chris -- =============================================================================== Chris Hafey * True programming is rebooting the machine chafey@ecst.csuchico.edu * after each crash until it works. ------------------------------ From: orestz@eskimo.com (Orest Zborowski) Subject: Re: blank_screen patch for Laptops (Questions) Date: Sun, 20 Mar 1994 04:23:13 GMT ... > I decided to do a cleaner mod for 1.0. > The following patch to drivers/char/console.c and include/linux/tty.h > adds the beginings of support for a user space daemon that can > function as a general screen saver--whether than means controllong the > backlight, or wastings cpu time on a fireworks display ;-) or > whatever. > What I need to do is add an ioclt to register the pid of said daemon > so that the kernel can signal it. > I also want to request comments on the signals to send to the daemon, > and whether some heuristic is needed to confirm the pid still existst. > I expect the daemon to set up its signal handlers, call the as-yet- > to-be-added ioclt to register itself, and wait for signals. The > handler for SIGTERM &c should call the ioclt to unregister itself. > Comments? ... In the VT code there is a similar arrangement for handling VT switches. You may want to use something like that for registering a system-wide blank server. This server can then accept requests from other processes that want to hang on to the blanking code. This makes for a cleaner interface between the kernel and the server - only a single process can gain control (and it can be written to be robust). Hardware-specific blankers can coexist with fun blankers, if there is some registration of blanking "type". -orest ------------------------------ From: orestz@eskimo.com (Orest Zborowski) Subject: Re: Linux for Sun4 Date: Sun, 20 Mar 1994 04:31:49 GMT M. Samid (smid@uni-paderborn.de) wrote: : Did someone know, if there exists a Linux version : for Sun4 SPARC stations? : I hope someone can say me a FTP-Adress. I don't believe there is a SPARC port of Linux. I thought it would be fun to try (and to write the 68k port for Sun3's you can buy pretty cheap), but I don't know if all the hardware information is publicly available, or if the code could be publicly available. -orest ------------------------------ From: kxb@cbs.ksu.ksu.edu (Karl Buck) Subject: Which finger? Date: 20 Mar 1994 08:07:51 -0600 I recently tried to get gnu finger to work and was not 100% successful (it refused to update the hostdata). So I tried falling back on the standard... which made me wonder: What is the "standard" finger package for Linux. I assume bsd, but even the various versions residing in sunsite.unc.edu:/pub/linux/system/Network/finger seem broken in one way or another. Any insight into this? --Karl -- Karl Buck USGMRL 913.537.3666 (H) 913.776.2745 (W) PGP public key available via finger. ------------------------------ From: Nickolay Saukh Subject: dialog-0.3 patches for 8 bit environment Date: Sun, 20 Mar 94 17:14:16 +0300 Reply-To: nms@saukh.suug.msk.su This patches depend on locale support. diff --unified --recursive dialog-0.3/src/Makefile dialog.new/src/Makefile --- dialog-0.3/src/Makefile Thu Jan 13 13:29:30 1994 +++ dialog.new/src/Makefile Sun Mar 20 17:08:23 1994 @@ -7,10 +7,10 @@ CC = gcc CPP = $(CC) -E -DEFS = -DHAVE_NCURSES -DBROKEN_WSCRL +DEFS = -DHAVE_NCURSES -DLOCALE LIBS = -lncurses -CFLAGS = -s -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer +CFLAGS = -O2 -Wall -Wstrict-prototypes -fomit-frame-pointer LDFLAGS = -s HDRS = dialog.h colors.h rc.h diff --unified --recursive dialog-0.3/src/dialog.c dialog.new/src/dialog.c --- dialog-0.3/src/dialog.c Thu Jan 13 13:31:54 1994 +++ dialog.new/src/dialog.c Sun Mar 20 15:36:58 1994 @@ -84,6 +84,10 @@ int offset = 0, clear_screen = 0, end_common_opts = 0, retval; char *title = NULL; +#if defined(LOCALE) + (void) setlocale(LC_ALL, ""); +#endif + if (argc < 2) { Usage(argv[0]); exit(-1); diff --unified --recursive dialog-0.3/src/dialog.h dialog.new/src/dialog.h --- dialog-0.3/src/dialog.h Thu Jan 13 13:05:13 1994 +++ dialog.new/src/dialog.h Sun Mar 20 13:20:15 1994 @@ -39,6 +39,9 @@ #endif +#if defined(LOCALE) +#include +#endif /* * Change these if you want diff --unified --recursive dialog-0.3/src/inputbox.c dialog.new/src/inputbox.c --- dialog-0.3/src/inputbox.c Wed Jan 12 18:02:30 1994 +++ dialog.new/src/inputbox.c Sun Mar 20 17:10:17 1994 @@ -29,7 +29,7 @@ { int i, x, y, box_y, box_x, box_width, input_x = 0, scroll = 0, key = 0, button = -1; - char instr[MAX_LEN+1]; + unsigned char instr[MAX_LEN+1]; WINDOW *dialog; /* center dialog box on screen */ @@ -112,7 +112,7 @@ } continue; default: - if (isprint(key)) { + if (key < 0x100 && isprint(key)) { if (scroll+input_x < MAX_LEN) { wattrset(dialog, inputbox_attr); instr[scroll+input_x] = key; @@ -128,7 +128,8 @@ waddch(dialog, key); } wrefresh(dialog); - } + } else + flash(); /* Alarm user about overflow */ continue; } } ------------------------------ From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: Real-Time Linux and a/d device drivers Date: Sat, 19 Mar 1994 21:04:20 GMT In article <2mdai5$iru@senator-bedfellow.MIT.EDU> gkm@tmn.com (Greg McGary) writes: >Now that I think about it, if multiprocessors become commodity items, >Linux won't necessarily want to go the preemptive kernel route. It's >much easier to implement a multi-processor system (with as many as 3 >or 4 CPUs) using a master-slave arrangement where CPU 0 runs all of >the kernel code--it owns all the devices and services all system >calls. The slave CPUs are scheduled to run user code only. Too bad this doesn't scale well. It works OK for two maybe three CPUs, but after that it falls flat on its face if you do lots of I/O. Too much waiting by the slaves on the master. That's why they went to a SMP kernel. At Solbourne they found that master slave gives very poor liniarity in adding CPUs to solving the problems. The curve gets flat at about three to five cpus (eg adding more doesn't help, and can hurt). At Sun, when the multi cpu systems came out, rumor had it the best way to speed up a 4 cpu machine was to remove two of the cpus. They also initially used a master slave kernel. VMS had a ASMP kernel for a while (for VAX 782). However, when they got serious about MP, they did a full SMP kernel with 5.0. However, ASMP (master slave) kernels are easier to write. They just don't scale well, as many peole have discovered. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder "... but I can't promote you to "Prima Donna" unless you demonstrate a few more serious personality disorders" ------------------------------ From: ani0349@cs.rit.edu (Anatoly N Ivasyuk) Subject: Re: Linux for Sun4 Date: Sun, 20 Mar 1994 17:32:04 GMT In article orestz@eskimo.com (Orest Zborowski) writes: >I don't believe there is a SPARC port of Linux. I thought it would be fun >to try (and to write the 68k port for Sun3's you can buy pretty cheap), >but I don't know if all the hardware information is publicly available, >or if the code could be publicly available. > >-orest I don't think you'll be able to get the hardware specs on Sun 3's, even though they are quite obsolete, without signing an NDA. This is part of the reason why students around here still do OS Lab on old Sun 2's, and yet we still have to sign NDA's. -Anatoly -- Anatoly Ivasyuk anatoly@nick.csh.rit.edu ani0349@cs.rit.edu ------------------------------ From: gt8134b@prism.gatech.EDU (Robert Sanders) Subject: Re: SIGIO with Non-Blocking sockets? Date: 20 Mar 94 17:47:05 GMT kwh@cs.brown.edu (Kwun Han) writes: >Linux, however, I am not getting the right behaviour. What I did was, >I first register the signal handler for SIGIO, then I established the >socket connection, then I used the ioctl -> FIONBIO, FIOSETOWN >FIOASYNC to make sure that the socket will signal my process when it Linux doesn't support signalled asynchronous I/O. It's been on my wishlist for a long time, but I've been too busy (and lazy) to do anything about it. -- _g, '96 --->>>>>>>>>> gt8134b@prism.gatech.edu <<<<<<<<<--- CompSci ,g_ W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W W@@@@**~~~' ro|- wpp@marie.physik.tu-berlin.de (Kai Petzke) writes: >kevin@frobozz.sccsi.com (Kevin Brown) writes: > >>In article jhenders@jonh.wimsey.com (John Henders) writes: >>>crfisher@nyx10.cs.du.edu (I am being repressed.) writes: > >>> So it helps people to encourage them to post to the wrong group, >>>does it? what about the people who are trying to use the group for the >>>reason it was created? Don't they count, in your worldview? > >>There is no good answer to this problem. Part of the reason it exists to >>begin with is that comp.os.linux.development is badly named because a lot >>of people wanted to be "cute" and have the abbreviation come out c.o.l.d. >>(otherwise, they would have been more sensible and just named the group >>comp.os.linux.kernel, ... > >Crerating a group comp.os.linux.kernel will not stop any problem. >People will start asking their kernel related questions in it. ...which is a lot better than them asking their software development related questions in it, which is what they do now, since kernel-related questions are much more often relevant to the actual charter of the newsgroup. >There is only one change: follow-up on each misplaces article on >c.o.l.d, saying, that this is the wrong group to place this >article, and that you would be happy to answer, if the question >is reposted to the right group. That might work, but perhaps not as well as you think. But I have to admit that it would be a lot better to do that (politely, of course) than to do what a lot of people do now, which is to flame the person asking the question into oblivion. It would probably work a bit better if, when responding as above, you mention which group is the right group. Perhaps what needs to happen is for comp.os.linux.help to be split up into various subgroups, each targeted to a particular type of question (admin, kernel, etc.) if you don't want *any* questions in comp.os.linux.development (which seems to be the case for a lot of people. I personally think it's absurd for a newsgroup to be chartered in such a way that questions generally aren't permitted. Mailing lists are much more appropriate for that kind of controlled discussion. But others will, of course, disagree). The reason for such a split is that people who like to specialize in answering certain types of questions won't have to scan through as many questions, and people asking questions might be able to expect a faster response. The caveat, though, is that despite such a split, no questioner should be reprimanded for asking any kind of question in any kind of help group, since it's supposed to be a *help* group. And, of course, the name of each newsgroup should make it as obvious as possible what it's for. For instance, the kernel questions newsgroup should be comp.os.linux.kernel.questions, which I think is slightly more obvious than comp.os.linux.kernel.help. >But you need a somewhat flame-proof asbestos west, if you do that >regularly. Perhaps. If you do it in a nice enough way, though, and do it in such a way as to give the other person enough information to go on (i.e., don't just say that this is an inappropriate group for the question, tell them what newsgroup *is* appropriate. If you don't know what newsgroup is appropriate, then you may as well answer the question, since you'd then be as in the dark as the person asking the question if it were *your* question), then you probably won't get many flames. It's the people who flame the questioner ("This is the wrong newsgroup. Go AWAY!!!") who will get flames for their response. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Real-Time Linux and a/d device drivers Date: Sun, 20 Mar 1994 12:21:09 GMT In article <2ma2rj$22a@genesis.ait.psu.edu> donadio@mxd120.rh.psu.edu (Matthew Donadio) writes: >Scott McClung (mcclung@squire.chinalake.navy.mil) wrote: >: Have I gone off the deep end to even ask these questions? I doubt that >: many of us need a RTOS, but it would be neat anyway... > >The people that neet real-time probably also have the money for >something like LynxOS or QNX and also have the money for a better >architecture like VME.... > >Seriously, what I would like to see is kernel level threads. Pthreads >exists right now, but only on the user level. Hmm...I'd think you'd be able to get cheap threads by doing the standard fork() semantics, with the caveat that you don't do copy on write, i.e. you get your own stack, pid, signal handler set (which you inherit from the parent), etc., but the data page set is identical between the two processes (such that the two processes basically use the same page table. A malloc() in one process causes both processes to see the extra memory, just like you'd expect), whereas you get a *copy* of the page table for a normal child process. There may be something I'm overlooking, of course (which wouldn't be surprising), but I'm somewhat convinced that between the above and some kind of semaphore implementation, you should be able to do pretty much everything you'd expect out of a "real" threads implementation. >Does anybody out there >know anythings about how hard this would be to implement? I don't >know much about kernel stuff (just a little about drivers), so I'm not >one to begin work on it... Beats me. It doesn't look like it would be very difficult on the face of it, but it depends on how the kernel implements processes. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kubla@goofy.zdv.Uni-Mainz.DE (Dominik Kubla) Subject: Re: Linux for Sun4 Date: 20 Mar 1994 19:24:00 GMT Since SPARC is an IEEE standard, it should be easy to obtain the specs, if you can afford whatever IEEE charges ... But given the difficulties the various m68k ports have, i doubt that you would be able to do this even as a part time job. But it would be fun to see this happen! :) Just my 2 , Dominik +-------------------------------------------------------------------------+ | eMail: kubla@goofy.zdv.Uni-Mainz.DE | | sMail: Dominik Kubla, Lannerstra"se 53, 55270 Ober-Olm, F.R. of Germany | +-------------------------------------------------------------------------+ DISCLAIMER: Everything written above are the expressed thoughts of the author and in no way connected to 'Johannes Gutenberg Universit"at', Mainz (Germany). This way, they do not have to care about what I say ... ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************