From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 14 Nov 93 08:13:08 EST Subject: Linux-Development Digest #226 Linux-Development Digest #226, Volume #1 Sun, 14 Nov 93 08:13:08 EST Contents: Re: Format of linux binaries (Rene COUGNENC) Re: Kernel accounting patches w/ 13 ALPHA (Louis P. Kruger) Re: Kernel accounting patches w/ 13 ALPHA (Louis P. Kruger) Re: Kernel accounting patches w/ 13 ALPHA (Louis P. Kruger) Re: Kernel accounting patches w/ 13 ALPHA (Louis P. Kruger) Re: 16550A handling in serial.c (Bryan M. Andersen) To - Do list for Linux (Teddy Winstead) vtwm for linux? (Robert Glamm) Re: Moving an X-Window from one computer to another. (David Barr) Re: Motif Project (Chad Phillip Brown) Re: Where is OI (Warner Losh) Re: [Q] Big modem installation for Linux? (Tim Smith) Re: Motif Project (Olaf Schlueter) Re: Motif - Pay? BAH! (Nicholas Ambrose) Re: Moving an X-Window from one computer to another. (Nicholas Ambrose) [Q] mmap implementation / persistency (Steven Buytaert) [Q] mmap implementation / persistency (Steven Buytaert) ---------------------------------------------------------------------------- From: rene@renux.frmug.fr.net (Rene COUGNENC) Crossposted-To: comp.os.linux.help Subject: Re: Format of linux binaries Date: 12 Nov 1993 16:43:19 GMT Ce brave Kuz I ecrit: > What do Linux binaries 'look' like. I mean in DOS, EXE files > have some kind of header before the actual program code, is > there something similar in Linux? Have a look to /usr/include/linux/a.out.h for example. (or just /etc/magic ) -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: lpkruger@flagstaff.Princeton.EDU (Louis P. Kruger) Subject: Re: Kernel accounting patches w/ 13 ALPHA Date: Fri, 12 Nov 1993 23:56:24 GMT In article <1993Nov10.022633.3314@princeton.edu>, I wrote: > I'm trying to apply the accounting patches which were written >for kernel 99.12. They also worked with 99.13 with a little bit >of hacking. Under 13p, I've managed to get everything to compile >except for the following line: > >ac.ac_btime=CT_TO_SECS(current->start_time)+startup_time; > >This appears in the function acct_process. The reason it doesn't work is >the global variable startup_time present in previous kernels no longer >exists. Can someone tell me what purpose this variable served so I >can try to finish the patching? Thanks a lot! > Thanks to the people who sent me email telling me what to change. For the benefit of others, here's what you can do: Just change startup_time to (xtime.tv_sec-jiffies/HZ) Then the kernel accounting patches will compile. Louis ------------------------------ From: lpkruger@flagstaff.Princeton.EDU (Louis P. Kruger) Subject: Re: Kernel accounting patches w/ 13 ALPHA Date: Fri, 12 Nov 1993 23:56:31 GMT In article <1993Nov10.022633.3314@princeton.edu>, I wrote: > I'm trying to apply the accounting patches which were written >for kernel 99.12. They also worked with 99.13 with a little bit >of hacking. Under 13p, I've managed to get everything to compile >except for the following line: > >ac.ac_btime=CT_TO_SECS(current->start_time)+startup_time; > >This appears in the function acct_process. The reason it doesn't work is >the global variable startup_time present in previous kernels no longer >exists. Can someone tell me what purpose this variable served so I >can try to finish the patching? Thanks a lot! > Thanks to the people who sent me email telling me what to change. For the benefit of others, here's what you can do: Just change startup_time to (xtime.tv_sec-jiffies/HZ) Then the kernel accounting patches will compile. Louis ------------------------------ From: lpkruger@flagstaff.Princeton.EDU (Louis P. Kruger) Subject: Re: Kernel accounting patches w/ 13 ALPHA Date: Sat, 13 Nov 1993 01:51:41 GMT In article <1993Nov10.022633.3314@princeton.edu>, I wrote: > I'm trying to apply the accounting patches which were written >for kernel 99.12. They also worked with 99.13 with a little bit >of hacking. Under 13p, I've managed to get everything to compile >except for the following line: > >ac.ac_btime=CT_TO_SECS(current->start_time)+startup_time; > >This appears in the function acct_process. The reason it doesn't work is >the global variable startup_time present in previous kernels no longer >exists. Can someone tell me what purpose this variable served so I >can try to finish the patching? Thanks a lot! > Thanks to the people who sent me email telling me what to change. For the benefit of others, here's what you can do: Just change startup_time to (xtime.tv_sec-jiffies/HZ) Then the kernel accounting patches will compile. Louis ------------------------------ From: lpkruger@tucson.Princeton.EDU (Louis P. Kruger) Subject: Re: Kernel accounting patches w/ 13 ALPHA Date: Sat, 13 Nov 1993 21:58:34 GMT Woops, I don't know why this got posted 3 times. I only submitted it once. It must the crummy news service we have here. Sorry about this! Louis ------------------------------ From: bmandrsn@news.weeg.uiowa.edu (Bryan M. Andersen) Subject: Re: 16550A handling in serial.c Date: Sun, 14 Nov 1993 00:37:04 GMT koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: >Another UART question (I have 4 16550As): >the normal UARTS do probing for the start bit synchronously with >16 times the baud rate (for 50 baud this is 800 Hz or 1.25ms). >Are any (pin compatible?) UARTs known which have a better >time resolution on start bit detection? >if not pin and plug compatible, are there any pc cards with such uarts? I don't see why any higher resolution would be needed. As the speed of the link goes up, start bit detection probing timeing also increases. Taking 16 samples per bit time would get you close enough to the real start time of the bit it shouldn't matter. The only hassel comes when trying to auto detect speed, but that is usuall done via softwear and using break signals to denote mis matched speeds. Having more samples complicates the hardware and dosen't increase accuracy significantly, it just raises costs and complexity. Oh, be thankfull they use 16, older UARTS often used 4 or 8 or were edge triggered which is a 1 x sampling frequency. -- Bryan M. Andersen Love over gender. ------------------------------ From: winstead@cs.tulane.edu (Teddy Winstead) Subject: To - Do list for Linux Date: 14 Nov 1993 04:34:54 GMT Has anyone ported xvtdl to Linux? Please let me know what needs to be done to this beast to make it compile, cause I can't figure it out. Thanks alot, and send e-mail if you think it'll save bandwidth Ted winstead@cs.tulane.edu ------------------------------ From: glamm@rushmore.ee.umn.edu (Robert Glamm) Subject: vtwm for linux? Date: Sun, 14 Nov 1993 05:40:18 GMT Has anyone compiled vtwm for Linux? If not, let me know if there is interest in this window manager; I'll try to compile it (v5.2.2). Thanks, Bob Glamm glamm@everest.ee.umn.edu -- Bob Glamm | There once was a programmer in C, 614 Delaware St. SE | Who had a very hard time with struct, did he; Minneapolis, MN 55455 | "My data I will scatter, glam0001@student.tc.umn.edu | throughout my program's grey matter," ------------------------------ From: davidb@stein3.u.washington.edu (David Barr) Subject: Re: Moving an X-Window from one computer to another. Date: 14 Nov 1993 06:15:21 GMT pablo@austin.ibm.com (Paul Greenwood) writes: >I'm not that big of a programmer but I was wondering if it would be >possible to write a program which could move an X-Window from one >computer to another. I have 1001 times wanted to go to an xterm and >type something like: > "xmove the.other.machine:0" >then go click my mouse on a window and have it appear on >"the.other.machine" and be a fully functional window. >Is this possible? If it is just an xterm session, then yes, you could do this by using "screen". Screen would let you have up to ten sessions within one xterm, and you can move those sessions to another terminal without interuption. The solution I presented is not X specific, but I don't know of a way to do this with X programs. David ------------------------------ From: yandros@news.mit.edu (Chad Phillip Brown) Subject: Re: Motif Project Date: 14 Nov 1993 06:44:25 GMT From: peter j dohm (dohm@cis.ohio-state.edu): Well i've been informed by a few people (and now that they mentioned it, I do remember seeing this in one of the CLARINET newsgroups.. my memory is going... :) that Motif has been adopted as the user-interface of choice in the COSE collaboration. If this is indeed the case, OSF *supposedly* will release Motif into the public domain for our consumption. Not quite, no. COSE will indeed be an ``open standard'' in that anyone can get the specification and do their own implementation. This does *not* mean that OSF's implementation will be free or in the public domain - they'll most likely continue to charge for Motif the way they do now - they'll just sell to more people (or, more likely, more vendors). Remember, if `Free Software' doesn't necessarily mean `Software for no price', then `Open Software' *certain;y* doesn't... It's worth mentioning here that I've heard rumours of at least two non-OSF Motif implementations - NCD's is supposedly especailly nice, but I've never seen any of them. I take this (if true - no idea, myself) to mean that anyone can do their own implementation if they like. That said, I'd be interested in working on such a free widget set sometime; right *now* I don't have the time (or the expertise, really) to do much, but that may change in the reasonably near future, especially given an interesting project to work on. :-) For work in this area, you could take a look a the 3D extensions to the Athena Widgets (Xaw3D) and whatever is currently coming out of the Free Widget Foundation (no joke! There really is such a group (albiet small)) Good luck. -- chad ------------------------------ From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: Where is OI Date: Sun, 14 Nov 1993 01:48:57 GMT In article kwh@cs.brown.edu (Kwun Han) writes: >Isn't it in tsx-11.mit.edu:/pub/linux/packages/OI ? Yes. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety. ------------------------------ From: tzs@stein3.u.washington.edu (Tim Smith) Subject: Re: [Q] Big modem installation for Linux? Date: 14 Nov 1993 11:34:08 GMT Byron A Jeff wrote: >Jesper Bach Larsen wrote: >>As headline says, I wan't to run a Unix installation, preferable Linux, as it >>is free, with multiple modem lines. By multiple I mean in the amount of >>30-50 modems. I suppose I will have to purchase somekind of hardware support ... >But all attached to 1 machine is an interesting project. Current DOS/Windows >based solutions I've seen have external controllers of some sort and of course >custom programming. Muy Expensive. Expensive compared to what? 50 reasonable modems are going to cost him several thousand dollars, and 50 phone lines are going to be several thousand dollars per year (assuming rates in his country are comparable to U.S. rates). Is an external controller expensive compared to the rest of his project? In fact, it seems strange for him to be concerned about the cost of the operating system. Even if he buys some commercial Unix for a thousand bucks, it sounds like that is going to be just a small part of his costs. --Tim Smith ------------------------------ From: olaf@toppoint.de (Olaf Schlueter) Subject: Re: Motif Project Date: 14 Nov 1993 11:05:55 +0100 yandros@news.mit.edu (Chad Phillip Brown) writes: >That said, I'd be interested in working on such a free widget set >sometime; right *now* I don't have the time (or the expertise, really) >to do much, but that may change in the reasonably near future, >especially given an interesting project to work on. :-) For work in >this area, you could take a look a the 3D extensions to the Athena >Widgets (Xaw3D) and whatever is currently coming out of the Free >Widget Foundation (no joke! There really is such a group (albiet >small)) Part of the FWF widgets are written in a web-like language which looks promising. The precompiler (wbuild) dumps core on my machine yet. If someone has already ported it successfully using it would surely boost up development speed. -- Olaf Schlüter, Sandkuhle 4-6, 24103 Kiel, Germany, Toppoint Mailbox e.V. "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." David Megginson ------------------------------ From: na2@doc.ic.ac.uk (Nicholas Ambrose) Subject: Re: Motif - Pay? BAH! Date: 14 Nov 1993 12:04:14 -0000 In article <2c0i88$plo@ground.cs.columbia.edu>, ringel@news.cs.columbia.edu (Matthew F. Ringel) writes: |> In article <2c0diq$9ro@pdq.coe.montana.edu>, |> Jaye Mathisen wrote: |> > |> >I am not a Mosaic user, but WTF does the choice of window manager have |> >to do with the libraries required to build a program? |> >-- |> > Jaye Mathisen |> |> Absolutely nothing. mwm is merely a window manager that is built |> with the motif libraries. Therefore you get the Motif look-and-feel |> without having to own the libraries. The confusion between having the |> libraries and having the window manager comes up every now and then in |> the comp.os.unix.* groups. |> |> ......Matthew yes, but arent all Motif apps dynamically linked in some way ? thus meaning that if you try to run stuff, you still need the libraries on the machine, as they are loaded at run-time ? Nick -- Furbling, v.: Having to wander through a maze of ropes at an airport or bank even when you are the only person in line. -- Rich Hall, "Sniglets" ------------------------------ From: na2@doc.ic.ac.uk (Nicholas Ambrose) Subject: Re: Moving an X-Window from one computer to another. Date: 14 Nov 1993 12:10:14 -0000 In article <2c4idp$jj@news.u.washington.edu>, davidb@stein3.u.washington.edu (David Barr) writes: |> pablo@austin.ibm.com (Paul Greenwood) writes: |> |> >I'm not that big of a programmer but I was wondering if it would be |> >possible to write a program which could move an X-Window from one |> >computer to another. I have 1001 times wanted to go to an xterm and |> >type something like: |> |> > "xmove the.other.machine:0" |> |> >then go click my mouse on a window and have it appear on |> >"the.other.machine" and be a fully functional window. |> |> >Is this possible? |> |> If it is just an xterm session, then yes, you could do this by using |> "screen". Screen would let you have up to ten sessions within one |> xterm, and you can move those sessions to another terminal without |> interuption. |> |> The solution I presented is not X specific, but I don't know of a way |> to do this with X programs. |> |> David well, why don't you just give xterm a display string when you load it up? ie "xterm -display the.other.machine:0" does this do what you wanted ? Nick -- Furbling, v.: Having to wander through a maze of ropes at an airport or bank even when you are the only person in line. -- Rich Hall, "Sniglets" ------------------------------ From: buytaert@imec.be (Steven Buytaert) Subject: [Q] mmap implementation / persistency Date: Sun, 14 Nov 1993 12:18:34 GMT [ Article crossposted from comp.os.linux.help ] [ Author was Steven Buytaert (buytaert@imec.be) ] [ Posted on Fri, 12 Nov 1993 16:28:15 GMT ] [ I didn't get any response, so I try this group. It has something to do with kernel development... ] Hello Linuxers, I have a question for those that already have dug deep down in the Linux kernel and library sources. I am in the process of evaluating a persistent storage system for my linux box. The system is called Texas and is currently at version 0.2. I'll give a small excerpt from the catalog of free databases at the end of this mail, describing what Texas is... Now, to be able to implement this library, they make use of: 1) currently, the mprotect system library call. (available on SunOS, Ultrix ... not in linux) 2) in future versions, the mmap library call. (implemented in linux) These are my thoughts and question: a) mprotect being not implemented is OK for me, since they will use mmap in the future. b) is mmap as implemented in Linux OK for this application ? To illustrate this I'll include an excerpt of my communication with the friendly people from Texas University (Thanks Sheetal). ----- I wrote Sheetal ----------------------------------------- |"No mprotect is not implemented in the kernel, [...] |On the other hand, what interests me more is |the mmap implementation." (From the context you will notice that |I also asked if the mmap on Linux is OK as it is now...) --------------------------------------------------------------- ----- He answered ------------------------------------------------- |"Actually, I am not sure if the mmap implementation (on Linux) |is "broken" or "incomplete" or "as intended". As I understand it, |mmap on Linux can map only character files into memory. This is |exactly similar to the mmap on Ultrix. I was talking to someone |here the other day, and I was told that the reason mmap is |implemented in such a way is because Linux (and Ultrix) are based |on BSD, which restricts mmap to map only character devices. |If this is so, then I don't think there is a question of |"fixing" mmap, since the current behaviour is probably what was |intended. Of course, I would be happy to be proven wrong on |this matter." ------------------------------------------------------------------- The question exactly is: can anyone who knows the kernel and the implemented library, can give comments on this? Thanks for reading so far. I will now, for the interested, give an excerpt of the catalog of free databases about what Texas is. ---------------------- Begin excerpt ------------------------------ "Texas is a simple, portable, high-performance persistent store for C++ using "pointer swizzling at page fault time" to translate persistent addresses to hardware-supported virtual addresses. Texas is built on top of a normal virtual memory, and relies on the underlying virtual memory system for caching. Texas is easy to use, and is implemented as a UNIX library. It is small and can be linked into applications. It requires no special operating system privileges, and persistence is orthogonal to type---objects may be allocated on either a conventional transient heap, or on the persistent heap, as desired. Texas supports simple checkpointing of heap data." ------------------------- end ------------------------------------- -- Steven Buytaert Interuniversity Micro Electronics Centre - Invomec Division Kapeldreef 75, 3001 Heverlee, BELGIUM phone : +32 16 281 271 fax : +32 16 281 584 e-mail : buytaert@imec.be In case of danger, BREAK glass -- Steven Buytaert Interuniversity Micro Electronics Centre - Invomec Division Kapeldreef 75, 3001 Heverlee, BELGIUM phone : +32 16 281 271 fax : +32 16 281 584 e-mail : buytaert@imec.be In case of danger, BREAK glass ------------------------------ From: buytaert@imec.be (Steven Buytaert) Subject: [Q] mmap implementation / persistency Date: Sun, 14 Nov 1993 12:26:38 GMT [ Article crossposted from comp.os.linux.help ] [ Author was Steven Buytaert (buytaert@imec.be) ] [ Posted on Fri, 12 Nov 1993 16:28:15 GMT ] Hello Linuxers, I have a question for those that already have dug deep down in the Linux kernel and library sources. I am in the process of evaluating a persistent storage system for my linux box. The system is called Texas and is currently at version 0.2. I'll give a small excerpt from the catalog of free databases at the end of this mail, describing what Texas is... Now, to be able to implement this library, they make use of: 1) currently, the mprotect system library call. (available on SunOS, Ultrix ... not in linux) 2) in future versions, the mmap library call. (implemented in linux) These are my thoughts and question: a) mprotect being not implemented is OK for me, since they will use mmap in the future. b) is mmap as implemented in Linux OK for this application ? To illustrate this I'll include an excerpt of my communication with the friendly people from Texas University (Thanks Sheetal). ----- I wrote Sheetal ----------------------------------------- |"No mprotect is not implemented in the kernel, [...] |On the other hand, what interests me more is |the mmap implementation." (From the context you will notice that |I also asked if the mmap on Linux is OK as it is now...) --------------------------------------------------------------- ----- He answered ------------------------------------------------- |"Actually, I am not sure if the mmap implementation (on Linux) |is "broken" or "incomplete" or "as intended". As I understand it, |mmap on Linux can map only character files into memory. This is |exactly similar to the mmap on Ultrix. I was talking to someone |here the other day, and I was told that the reason mmap is |implemented in such a way is because Linux (and Ultrix) are based |on BSD, which restricts mmap to map only character devices. |If this is so, then I don't think there is a question of |"fixing" mmap, since the current behaviour is probably what was |intended. Of course, I would be happy to be proven wrong on |this matter." ------------------------------------------------------------------- The question exactly is: can anyone who knows the kernel and the implemented library, can give comments on this? Thanks for reading so far. I will now, for the interested, give an excerpt of the catalog of free databases about what Texas is. ---------------------- Begin excerpt ------------------------------ "Texas is a simple, portable, high-performance persistent store for C++ using "pointer swizzling at page fault time" to translate persistent addresses to hardware-supported virtual addresses. Texas is built on top of a normal virtual memory, and relies on the underlying virtual memory system for caching. Texas is easy to use, and is implemented as a UNIX library. It is small and can be linked into applications. It requires no special operating system privileges, and persistence is orthogonal to type---objects may be allocated on either a conventional transient heap, or on the persistent heap, as desired. Texas supports simple checkpointing of heap data." ------------------------- end ------------------------------------- -- Steven Buytaert Interuniversity Micro Electronics Centre - Invomec Division Kapeldreef 75, 3001 Heverlee, BELGIUM phone : +32 16 281 271 fax : +32 16 281 584 e-mail : buytaert@imec.be In case of danger, BREAK glass -- Steven Buytaert Interuniversity Micro Electronics Centre - Invomec Division Kapeldreef 75, 3001 Heverlee, BELGIUM phone : +32 16 281 271 fax : +32 16 281 584 e-mail : buytaert@imec.be In case of danger, BREAK glass ------------------------------ ** 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 ******************************