From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 23 Nov 93 17:13:22 EST Subject: Linux-Development Digest #253 Linux-Development Digest #253, Volume #1 Tue, 23 Nov 93 17:13:22 EST Contents: Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? (Michael Hoegeman) Re: Some ideas and reasons for a more modular kernel. (Tim Smith) Re: Don't use Motif for free sw: it now requires runtime royalties! (Shane Hartman) [Q] >2 IDE HD's with linux (Patrick TjinPitJoen) Need help on lmscd0.2. (Timothy E. Neto) Re: Don't use Motif for free sw: it now requires runtime royalties! (Rick Richardson) Reading IP addresses from a RAW socket (enrico badella (L.R.)) corewar (Steef S.G. de Bruijn) Re: rawrite.exe is too slow (Steef S.G. de Bruijn) T130B SCSI drivers - should I write one ? (Andrew Davison) Dosemu0.49 bug fix. (Ronnie Sahlberg) Re: Simple question, why no fsck for xiafs (Scott D. Heavner) c++ xwindow (Laurent Chavey) Driver for Mitsumi FX001D? (Arthur van Leeuwen) Re: Creeping featuritis (post --rant --flame) (Richard Brooksby) Re: Don't use Motif for free sw: it now requires runtime royalties! (HALLAM-BAKER Phillip) ---------------------------------------------------------------------------- Crossposted-To: comp.windows.x,comp.windows.x.motif From: mh@awds.imsd.contel.com (Michael Hoegeman) Subject: Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? Date: Tue, 23 Nov 1993 06:39:49 GMT Robert Nicholson (robert@steffi.demon.co.uk) wrote: : hasty@netcom.com (Amancio Hasty Jr) wrote : >Big Flame Thrower on :-) : > : >Check out SimCity Demo for what tcl/tk is capable of. : >BTW: At work I developed a mini network management platform all based : >in tcl/tk/snmp/expect and it works like a charm. : > : >I say that is far easier to develop X oriented apps using tk than : >Motif and save an order of magnitute of develpment time and : >size of the application. : > : >Amancio : > : : Can we stop this TCL/TK is better than Motif thread? I see them as : being orthogonal products. TCL hasn't the feature set nor the : elegance to be considered "suitable" for large application development I don't agree on them being "orthogonal products". I think your problem is that you view see TCL as being a hard to extend monolithic interpreter. TCL **is meant to be extended** it's not something that supposed to avoided at all costs. : work. Do people advocating TCL know the benefits of Object-Oriented : Design? Sorry 'send' just doesn't cut it for me I'm afraid. And Motif along with some kludgy C++ binding exploits the benefits of object oriented design?? Not in my opinion. : I will accept that TK is suitable for whipping up prototype (abeit, : throw away ones but maybe that's actually an advantage. :-)) : applications or relatively small applications that require little maintenance. I would guess that the Tk/Tcl simcity is more than just a whipped up protoytpe. If it *is* a whipped up prototype you certainly cannot 'whip up' a simcity in Motif. Tk/Tcl allows many programs to be "small" that would not be that way if implemented in Motif. : A very good one that I use regularly is Tkman by Tom Phelps. True. It's a good example of what you can do with just the out-of-the-box wish interpreter. But script-only applications are not the only kind of Tk/Tcl application in town. : I'd certainly be interested in a discussion of the merits of TCL/TK : mixed with C++ though for application development. Me too. the first to remember is that you don't have to limit yourself to just using the stock wish. You can write big chunks of your application in C or C++ freely. It takes a little while to get used to writing applications this way but it is very effective. For example, I work on a weather forecasting system that uses Tk/Tcl which is quite large. We have weather product objects which are subclassed into things like satellite images, maps, vector graphics, textual observation telegrams, etc.. The methods for the objects like read, write, display etc.. have Tcl bindings that work in conjunction with a "weather graphic" Tk widget. This approach lets us build various weather visualization programs in a way that's very productive. : Personally I'd like to see a tklib written in C or C++ rather than : relying on tcl bindings. Why? maybe you can give me some rough examples of why you want this. as i'm not convinced of the utility in it. e.g., why would you want to build all your pull-down menus with C++? It does not make a lot of sense to me. -- ============================================================================== Mike Hoegeman email: mh@wx.gtegsc.com tel: (818)706-4145 GTE Weather Systems Group 31717 La Tienda Dr, Westlake Village CA. 91359 ------------------------------ From: tzs@stein3.u.washington.edu (Tim Smith) Subject: Re: Some ideas and reasons for a more modular kernel. Date: 23 Nov 1993 06:29:09 GMT Ed H. Chi wrote: >>kernels. What it needs is an automated way of generating a kernel symbol >>map. I was hoping Linus will get around to incorporating into the kernel ... >This loadable driver thing has been talked about before, and people just >said, "there is this module thing on the QIC-80 directory." There has >been no move of it into the standard kernel distribution. Is there something about Linux that makes loadable drivers hard? (I don't have Linux, so can't look for myself). I added them to ISC Unix when I worked at ISC, and it was easy. If I recall correctly, here's how we did it. This should be adaptable to any Unix-like system. Kernel Changes 1. A system call was added to allocate memory in kernel space and return the address of that memory to the caller. Another call was added to free such memory. 2. A system call was added to add an interrupt handler. It took an interrupt number and the address of a kernel routine that was to become the handler for that interrupt. Another call was added to to remove an interrupt handler. 3. A system call was added to initialize a driver. 4. Global variables were added that contained the number of entries allocated for various kernel tables (e.g., for the block device table, the character device table, etc.). Kernel Configuration Changes 1. The kernel configuration scripts were modified to run nm on the kernel before striping it. The result was saved somewhere. 2. The block and character device tables were padded with unused entries. All other tables that had one entry per driver (or per stream module, etc.) were also padded with extra entries. Here's how you load a driver. 1. Use sed, awk, or whatever, to turn the symbol list from nm into an assembly source file that just defines all the kernel symbols as external absolute addresses. 2. Assemble this, to get a .o file that can be used to resolve references to kernel routines. 3. Use the memory allocation system call to allocate space for the driver. 4. Use ld to link the driver with the .o that defines the kernel symbols and relocate it to the address that it will be loaded at. 5. Use nm to get the addresses of the driver open, close, strategy, etc., routines. From this, we can figure out where they will be when the driver is loaded. 6. Read the linked driver, extract the code and data, and copy them to the kernel, using /dev/kmem. 7. Add entries for open, close, etc., by patching the appropriate tables in /dev/kmem. 8. Use the system call that adds an interrupt handler to add add the driver's interrupt routine. 9. Use the system call that tells the kernel to init a driver to get the driver initialized. I'm probably forgetting details, but that's the gist of it. Is there any reason this sort of scheme couldn't be done easily on Linux? (In case anyone is wondering, the reason you never saw this if you bought ISC Unix is that they had me do this to work around a boot limit. The boot program had a size limit on the kernels it could load, and that was smaller than the size of a kernel with all the networking and X stuff in it. Hence, they wanted to go to loadable drivers to keep the kernel at boot time small enough to load. However, for other reasons, they had to rewrite the boot, and the size limit went away, and they forgot about my loadable driver code. This was the last thing I worked on there, and apparently fell through the cracks when I left. What was really annoying was that my first assignment at my new job was to write a driver for ISC Unix, and loadable drivers would have really sped up my development). --Tim Smith ------------------------------ From: shane@nugget.spr.com (Shane Hartman) Date: 23 Nov 1993 04:20:45 GMT Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Reply-To: shane@spr.com In article arnej@imf.unit.no (Arne Henrik Juul) writes: > How about: > "there is a difference between free quality software and commercial stuff" ? > > That's just as true. > I prefer: > - fast response to bug-reports. > - being able to fix bugs myself if I'm able and need it. > - getting my bug fixes back into the master version. > > The third point is difficult-to-impossible with commercial software. > With free software, it's *always* possible, and most often very easy. Yeah, right. That's great for those of us with the skill and time to do this. I just love getting new releases of emacs and debugging it (again) on three platforms. Makes my day. Like it or not, you are in the minority. Now that Motif is going to be bundled with all COSE platforms in the near future, it makes NCSA's job easier to target a standard platform (which tcl/tk is certainly not). NCSA's decision is quite reasonable from a software developer's viewpoint (especially one that isn't paid). If you guys don't like it, then write your own frigging browser using whatever libraries you choose. Personally, I would rather spend $400 to buy Motif than spend a month or so writing a browser to another API. My time is worth more than $400 a month. -- K. Shane Hartman | SPR, Inc. is not responsible for Software Productivity Research, Inc. (SPR) | any opinions expressed above. 1 New England Executive Park | Phone: (617) 273-0140 x114 Burlington, MA, USA 01803-5005 | Fax: (617) 273-5176 ------------------------------ From: pattjin@ucsee.EECS.Berkeley.EDU (Patrick TjinPitJoen) Subject: [Q] >2 IDE HD's with linux Date: 23 Nov 1993 07:34:19 GMT I was wondering if anyone has a patch that will enable linux to work with > than 2 IDE HD's...there are device drivers for DOS that allow up to 4 IDE HD's (using the secondary IDE port at 0x170 (i believe)). Pat ------------------------------ From: ten0772@halcyon.com (Timothy E. Neto) Subject: Need help on lmscd0.2. Date: 22 Nov 1993 23:31:32 -0800 Hi all, I look through the README file for the writer's address, but I couldn't find it, so I'm posting a message here. I'm trying here in the development group, hoping I'll catch the writer's attention. I'm appreciative to be able to be an Alpha tester. So here is my error, $make zImage kernel chr_drv sound make[3]: `sound.a' is up to date. blk_drv gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -m486 -c lmscd.c lmscd.c: In function `sec2fsm_bcd': lmscd.c:374: `asm' needs too many reloads gcc: Internal compiler error: program cc1 got fatal signal 6 make[2]: *** [lmscd.o] Error 1 make[1]: *** [kernelsubdirs] Error 1 make: *** [linuxsubdirs] Error 1 $ I'm running Linux 0.99pl13 with the atdisk2 patch on a Gateway 4DX2-66V system. I have the Gateway internal LMS-CM205 CDROM drive. My O/S is built up from the SLS1.02 package, JANA May/June CDROM, and some Slackware 1.1.0 libraries. My trouble is that I'm not to familiar with 386/486 asm syntax. The C code I can comprehend and follow, asm? That I still have to work with and experience. So, what is a "reload" error? What do I need to adjust? Thanks for any assistance. Later... -- Indecision is the key | Timothy E. Neto 1 000 to flexibility. | Neat'o Gadget & Widget Works 1 0. .0 You can't E-Mail God. | Unix & X Applications Development 1 0 _ 0 Opinions are all mine. | Seattle, WA ten0772@halcyon.com 1 000 ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: rick@digibd.digibd.com (Rick Richardson) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Tue, 23 Nov 1993 06:52:19 GMT muts@compi.hobby.nl (Peter Mutsaers) writes: >Better yet, lets make sure that Motif will not dominate the GUI. What >customers want is a Motif *look and feel*, they don't care how it is >implemented. But what developers have been crying for is a standard *API*. Read that as: a set of dynamic libraries guaranteed to be available on the end users sytem. The users will use whatever LAF has the most available applications for it. The developers will develop to whatever API has the broadest availablity (and thus end-users). COSE could have chosen the Windows 3.1 API, for all we care (and it might not have been such a bad idea). What matters is that one (the Motif API) was chosen. Developers are free to ignore the provided API, but if they do, they risk the rath of customers with 16MB machines that can't tolerate another set of dynamic libraries (or statically linked binaries) eating up RAM. -Rick -- Rick Richardson Senior Staff Engineer NCSA Mosaic - DigiBoard, Inc. Email: rick@digibd.com #1 reason for a national 6400 Flying Cloud Dr. Fax: (612) 943-0803 (toll-free) data highway. Eden Prarie, MN 55344 Tel: (612) 943-5383 ------------------------------ From: badella@polec1.polito.it (enrico badella (L.R.)) Subject: Reading IP addresses from a RAW socket Date: 23 Nov 1993 07:48:59 GMT Hello, I'm porting to Linux a home grown ping; it uses a SOCK_RAW socket and ICMP protocol. I have discovered that I cannot reliably read the ip address of of the remote party by directly looking into the packet with this line of code recvfrom(s, packet, len, 0, &clifrom, &fromlen) ip = (struct ip *) packet; pack->s_addr = htonl(ip->ip_src.s_addr); but I must read the address from the socket with recvfrom(s, packet, len, 0, &clifrom, &fromlen) ip = (struct ip *) packet; pack->s_addr = htonl(clifrom.sin_addr.s_addr); This isn't really a problem for my application but I was just wondering why it works on all the platforms I have ported to (Sun, SGI, HP, SCO-ODT) and only fails on Linux. eb ------------------------------ From: debruijn@cs.utwente.nl (Steef S.G. de Bruijn) Subject: corewar Date: Tue, 23 Nov 1993 10:01:39 GMT Haw's thas? A Thank thas as mach fannaar than Anglasch! CA, Staaf -- S.G. da Braaan Twanta Anavarsata af Tachnalay, Dapt. af Campatar Scaanca E-Mail: debruijn@cs.utwente.nl ##### / \ < o o > | C | Stavaa "SpakarJack" da Braaan /--\___/--\ / |o \ / /| |o |\ \ / / | |o | \ \ -- | |o | -- --------- Plannang as a daffacalt thang... Asang Lanax as nat! ------------------------------ From: debruijn@cs.utwente.nl (Steef S.G. de Bruijn) Subject: Re: rawrite.exe is too slow Date: Tue, 23 Nov 1993 10:08:33 GMT Ng Pheng Siong (ngps@nova.np.ac.sg) wrote: : In article , : Orest Zborowski wrote: : >One of the reasons rawrite is slow is that it only writes 3 sectors at a time, : I use rawrite under OS/2 2.1, and it is much faster than whe run under Dos. Why is it's speed interesting? You only need it if you have only DOS, AND only the bootfloppy has to be RA-written.. Steef -- S.G. de Bruijn Twente University of Technoloy, Dept. of Computer Science E-Mail: debruijn@cs.utwente.nl ##### / \ < o o > | C | Stevie "SpikerJack" de Bruijn /--\___/--\ / |o \ / /| |o |\ \ / / | |o | \ \ -- | |o | -- --------- Planning is a difficult thing... Using Linux is not! ------------------------------ From: davison@bruce.cs.monash.edu.au (Andrew Davison) Crossposted-To: comp.os.linux.help Subject: T130B SCSI drivers - should I write one ? Date: 23 Nov 1993 10:29:36 GMT Is anybody working on a driver for the Trantor T130B SCSI Adapter ? Having just purchased a gig drive so that I could play with linux, I was a little more than disappointed to find the controller not supported. If there is nobody working on this, would somebody like to drop a few hints on how one would go about writting such a beast ? I might be inclined to spend some of my non-existant spare time doing the deed. Regards, Andrew ------------------------------ From: ronnie@lysator.liu.se (Ronnie Sahlberg) Subject: Dosemu0.49 bug fix. Date: Mon, 22 Nov 1993 17:58:49 GMT This is a fix for the keyboard interrupt routines under dosemu 0.49. With this fix, the game PinballDreams runs perfectly under the dos emulator. What ths fix does should be quite obvious. (sorry, no diff) In file : dosipc.c : ============================================= void sigipc(void) { struct ipcpkt pkt; (ADD) struct timeval tv; (ADD) fd_set fds; (ADD) (ADD) /* signals dont queue, but packets do . */ (ADD) do { I_printf("IPC ... ================================================ default: I_printf("IPC... } (ADD) /* check if more than one packet arrived with signal*/ (ADD) FD_ZERO(&fds); (ADD) FD_SET(PARENT_FD,&fds); (ADD) tv.tv_sec=0; (ADD) tv.tv_usec=0; (ADD) } while( select(255,&fds,NULL,NULL,&tv)==1 ); ================================================== The problem was that sometimes, especially when I was playing PinballDreams, several packets (keypresses) would arrive with the same signal, thus making the game almost impossible to play. The program EDIT under DOS still doesnt work properly even if you apply this patch. I have no idea whatsoever why EDIT doesnt work :-( ronnie. ronnie@lysator.liu.se ------------------------------ From: sdh@fishmonger.nouucp (Scott D. Heavner) Subject: Re: Simple question, why no fsck for xiafs Date: Tue, 23 Nov 1993 01:10:46 GMT Reply-To: sdh@po.cwru.edu David Jeske (jeske@ux4.cso.uiuc.edu) wrote: > I do not want to start a "ext2"/"xiafs" fight. I'm just wondering, is > there a specific reason that there is no fsck for xiafs? Or has everyone > just decided that it's unnecessary because of ext2? What about Frank Xia, > did he plan to do a fsck and then quit? > I'm not looking for someone to convince me to run ext2 (I *DO* run ext2) > Also, if for some reason I'm extremely misinformed and there is a fsck > for xiafs, please point me in the right direction. I use xfsck, which is what I think Frank intended when he released the xiafs support programs. Somewhere on tsx-11 you should be able to find xiafspgm-0.8.tar.z which contain the source for fsck and mkfs for the xiafs (try pub/linux/BETA/xiafs). Scott ------------------------------ From: chavey@nori.cis.udel.edu (Laurent Chavey) Subject: c++ xwindow Date: 23 Nov 1993 12:45:56 GMT I am looking for some c++ classes to do some xwindow programing. I am lokking for something not too fancy, documented and free. Now that is a lot of restrictions, but I remember seeing something on the net about 2 month ago. anyone can point me to the source. thank you. ------------------------------ From: arthurvl@sci.kun.nl (Arthur van Leeuwen) Subject: Driver for Mitsumi FX001D? Date: Tue, 23 Nov 1993 12:40:52 GMT Hi, Last saturday I bought an Mitsumi CD-ROM drive, but when I had it installed the linux-kernels I had didn't recognize it. It's a dual-speed multi-session drive. Does anybody have drivers for this particular CD-ROM drive or could somebody help me writing it? It's an MITSUMI FX001D. Bye, -- <> <> Arthur van Leeuwen <><> <> arthurvl@sci.kun.nl <>--<> <> You may not reproduce anything that was written here <> <><><>< by me, in any way. Even if you like to ::-) ------------------------------ Crossposted-To: gnu.misc.discuss From: richard@harlequin.co.uk (Richard Brooksby) Subject: Re: Creeping featuritis (post --rant --flame) Date: Tue, 23 Nov 1993 12:21:24 GMT kjetilho@ifi.uio.no (Kjetil Torgrim Homme) wrote: > This is an example of a thing that will be reasonable to do in the > Hurd or in Linux. Until now, GNU utilities have been merely adding > functionality to existing Unix implementations. Part of the reason I'm bringing this up now is that we _have_ Linux, and may soon have HURD, and I bet they'll just (continue to) import the existing GNU tools with all their obsolete and irrelevant, and resource-grabbing features. I wrote: > > The saddest of all: cat -n You replied: > I'm terribly sorry, but what should I use instead? I'm rather fond of > this "trick": > for i in `yes "" | cat -n | head -100`; do ... I hope you don't write this sort of thing _and_ complain about the speed and memory requirements of other people's software. > David/Elizabeth suggests pr(1), and I can do that with IRIX (SysV) or > GNU pr (pr -n -l1), but not SunOS pr. Of course, IRIX' cat doesn't > understand "-n". nl(1) Look, I don't think cat -n is stupid for aesthetic reasons. It's stupid because it signifcantly complicates the operation of cat. Unless you foolishly write cat as line-in line-out (or even, horrors, char-in char-out) then cat -n is an entirely different program to cat! So, what we end up with are several different programs glued together in some unholy manner in the same binary. Bad design! The result: bad code, bugs, unmaintainability, inefficiency, and, in the end, major software disasters. The point is that you can have simplicity, efficiency, _and_ power! Simplicity of design means faster development, fewer bugs, adaptability. In an ill though-out rush for the power, we are sacrificing more important long-term principles. --- Richard Brooksby Technical Manager (Harlequin) / Parallel Compiler R&D / Esprit COMPARE Project Research and Development / MLWorks Project / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: hallam@dxal18.cern.ch (HALLAM-BAKER Phillip) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Reply-To: hallam@alws.cern.ch Date: Tue, 23 Nov 1993 13:01:13 GMT In article , aad@dvorak.amd.com (Anthony A. Datri) writes: |>Xref: dxcern comp.infosystems.www:3501 comp.windows.x:69729 comp.windows.x.i386unix:5385 comp.windows.x.motif:21250 gnu.misc.discuss:12425 comp.os.linux.development:3024 comp.sources.d:8570 |>>I would guess none whatsoever. Mosaic *is* a Motif interface to libwww. If |>>you want to have another interface then you would throw out virtually all of |>>Mosaic. |> |>Huh? How can Mosaic's functionality *possibly* depend on pseudo-3D art-deco |>borders around everything? Because it uses the common library of World Wide Web code. This contains routines that resolve anchors, access servers, parse SGML etc. If anyone wants a TCL W3 client then they are quite welcome to the code. CERN made it publicaly avaliable (not sure about the exact restrictions, but certainly they are GNU-ish). If TCL is as easy to use as is claimed a rough and ready type browser but with full functionality should take no more than a week, But it will take you at least a year to transform a hack into a comercial quality system. Here is a start: So TCL people quit bitching and start coding! If you had spent half as much time coding as bitching you might be finished by now. I can understand the people who don't want to pay for software. But I don't see why they should force the rest of us to follow them. The Xmosaic people have produced a good product that they make avaliable without charge. It requires the purchase of two things to run it, a computer and Motif. Should NCSA only write code that runs on free computers? -- Phillip M. Hallam-Baker Not Speaking for anyone else. ------------------------------ ** 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 ******************************