Linux-Development-Sys Digest #43, Volume #7 Wed, 11 Aug 99 15:14:29 EDT
Contents:
Re: GCC byte alignment flag for structures (Matthew Carl Schumaker)
Re: MICROSOFT LINUX DISTRIBUTION (H. Peter Anvin)
Re: Linux assembly, etc (Johan Kullstam)
Re: My first linux program: non-bios boot loader (Etienne Lorrain)
The generic SCSI driver (Jonas Persson)
Can a process be "out schedualed" while in a system call? ([EMAIL PROTECTED])
Re: Device driver programming (Kaz Kylheku)
Re: how to tell a process is background? (Stuart R. Fuller)
rc.local or command line (Vyl Chan)
Re: Sockets, FIOASYNC etc. AAAAAAAGh! (Steven J Haeck)
Re: My first linux program: non-bios boot loader (Neil Koozer)
Re: My first linux program: non-bios boot loader (Neil Koozer)
Re: My first linux program: non-bios boot loader (H. Peter Anvin)
----------------------------------------------------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC byte alignment flag for structures
Date: Wed, 11 Aug 1999 09:39:19 -0400
Matthew Carl Schumaker
UPAC Lights Administrative Chairperson
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
On 10 Aug 1999, Michael Meissner wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> For most implementations, the structure mapping might be what you expect, but
> using a structure with ints, etc. is still is not the way to write portable
> code because sooner or later you might encounter a system with a different
> packing, endianess, sizeof of basic types, etc.
>
> Generally for stuff coming in over the wire, you need to have a char array that
> holds the raw bytes, and a structure with native fields, and you build up the
> fields byte by byte. For example, if your structure is and the order of bytes
> on the wire is little endian:
>
> struct foo {
> char a;
> char b;
> short c;
> };
>
> You would need two translators function of the form:
>
> void foo_in (unsigned char *in, struct foo *out)
> {
> out->a = in[0];
> out->b = in[1];
> out->c = (in[3] << 8) | in[2];
> }
>
> void foo_out (struct foo *in, unsigned char *out)
> {
> out[0] = in->a;
> out[1] = in->b;
> out[2] = (in->c & 0xff);
> out[3] = ((in->c >> 8) & 0xff);
> }
>
> > Of course if e.g. all servers/clients are prepared to handle big or little
> > endian (whatever was chosen) on the wire that is not broken at all, but
> > a valid design.
> > He just has to make sure that the programs running on hosts with different
> > byte sex always convert.
>
> And sooner or later will find a machine with different assumptions.
I fail to see your point, of course I would have modifiy the data if i
were using a different platform, you have to do that, hence htonl ntohl
calls but the original point of my post was that there is already a
platform being used on the client side that was expecting the structure in
a certain byte alignment.
YOur post seems to take the view (correct me if
i'm wrong) that instead of only having to do modifications on certain
machines that have different byte ordering for ints, every platform should
have to do, thus having to add overhead to every application on every
platform instead of only a few. If I have a network with 600 Wintel
machines and 2 Mips you can bet I'm going to use a structure that the
Wintel machines can use with out having to do anoyying byte shifting
As for Merced and such If I declare a 4byte int do you really think the
byte order is going to be different whether I use a PII 300 or a Merced
I sincerely doubt Intel would change that
I think it was my computer organization prof that said
"Make the common case fast"
That was behind the decision since these apps deal with near realtime data
and the less time spent doing byte shifting the better
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: 11 Aug 1999 12:57:59 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <7oq43f$v61$[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> Since I have novell 4.2 running on top of my linux box I found out that
> it doens't use server.exe instead you use the linux version writen but
> some german guy called mars_nw... works really slick if you as me and
> it actually is supost to outperform that MS-DOS server.exe.. I am still
> testing to see if that is true.
>
If you're using mars_nwe, then you're not actually running Novell, but
a (free!) clone.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Linux assembly, etc
Date: 11 Aug 1999 08:54:26 -0400
Josef M�llers <[EMAIL PROTECTED]> writes:
> Alexander Viro wrote:
> > =
>
> > In article <[EMAIL PROTECTED]>,
> > Johan Kullstam <[EMAIL PROTECTED]> wrote:
> > >of course it's not *really* a shared library. however, on the surface=
>
> > >it shares a couple of attributes:
> > >
> > >1) system calls are done by a C subroutine call mechanism. in x86 you=
>
> > > push args onto the stack and use a `call' instruction.
> > =
>
> > Check the facts, please. It's done by putting the values into registers=
>
> > followed by int 0x80. No trace of call. We are *not* using the call
> > gate - it's a trap gate and nothing is copied from the caller's stack.
> > Check arch/i386/kernel/{trap.c,entry.S} for details. Or just do the fol=
> lowing:
> > al@bird:/tmp$ ar x /usr/lib/libc.a write.o
> > al@bird:/tmp$ objdump --disassemble write.o |less
>
> Could it possibly be that you two (Alexander and Johan) happily talk
> past another?
no. alexander is right. i was wrong.
> If I wrote a C program, I would initiate a system call (e.g.
> open/close/read/write) by calling a subroutine/function (possibly) in
> the standard-C-library (g)libc. This is usually but not necessarily a
> shared library. My process would still be in user land, parameters would
> (usually) be passed by pushing them onto the stack and retrieving them
> from there. The passing of arguments and the calling of functions is a
> compiler issue.
> (This is Johan's point of view)
i was thinking that calls to kernel would be patched with the proper
addresses at load time. this is not the case for ia32/x86 linux.
> The library function would then, in turn, do the actual system call,
> e.g. by loading the parameters into registers and executing an INT
> instruction. This would switch into system mode and enter the kernel.
> This is a kernel implementation issue.
> (This is Alexander's statement)
yes.
> Having a library between the user code and the kernel call has the
> advantage that the source code is independent of the kernel-entry
> mechanism: No matter how the transition from user to kernel mode was
> implemented, INT 0x80, CALL gate, SYSCALL instruction, or even
> attempting to execute an illegal instruction, the source code would
> still refer to it as a function. Some "system calls" may even be
> implemented partially or wholly in user land, e.g. a kernel
> implementation may choose to map the proc structure read-only into the
> user address space, getpid(), getuid() and friends would then require no
> entry into kernel mode.
you are correct. the C wrappers of the actual kernel calling
mechanism allow easy porting of the C code. this has been a big win
for unix and C.
> Having a shared library has the additional advantage that a program
> gains a certain degree of binary portability, because the transition
> code is added at runtime and a different library may be linked at
> program start time to reflect the change in calling method.
>
> Hoping to end a senseless debate,
not senseless. i have learned something. i hope others have too.
--
johan kullstam
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: My first linux program: non-bios boot loader
Date: Wed, 11 Aug 1999 15:20:58 +0100
"H. Peter Anvin" wrote:
> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> > Also, if the installer (the equivalent of your muni.c) is
> > written in real mode, it can exactly detect which kind of
> > BIOS is available (at least 4 kinds), what is the understanding
> > of the disk geometry by the BIOS, and be sure to provide
> > what is necessary at the next boot. Moreover, because I do
> > not plan to modify the second stage bootloader while Linux
> > is running, this file can be marked as "imuable", i.e.
> > read only even for root (but in runlevel 1), so luser-root
> > will always have a booting PC.
>
> There are two problems with this: first of all, you need to get to
> real mode to install (and within Linux, you can't get to a "clean"
> BIOS),
Note that my aim was to install the second bootloader _once_,
i.e. on the first time the PC is powered up before installing
Linux. That is why I would like ext2fs (and maybe fdisk) in real
mode, the second bootloader should be able to find all kernel
available on every partition present at next power-on,
without modification, and be in an imuable file.
I also want to have a clean dis-installer, so a backup of
the boot block is saved, and you can remove gujin even if
your Linux install is not working at all. I am tired seeing
people using "fdisk /mbr" instead of "lilo -U".
> and second of all, if you move the disk to a different system
> it may no longer boot.
Lets be clear here, it is only happening when using standart
disk BIOS (not EBIOS) with more than 1024 cylinder, and for the
second bootloader only, but yes I have this problem.
In this case, I would prefer to use the hard IDE driver, LBA if
the disk support it, or CHS using Linux conventions (i.e. cylinder
up to 16 bits, as Linux native driver uses it). Then, gujin
will continue to boot even if the new BIOS does not support
anything more than 1024 cylinder.
Note that the bootsector and the second bootloader does not
need to be on the same disk (a PC brought with winblows on
one big partition and another disk to try Linux), so
changing some of the disks will not always work.
> In lbcon I'm doing this determination at boot
> time rather than install time for these reasons. The problem, of
> course, is that one has to *really* shoehorn stuff into the boot
> block...
In choosing between an IDE driver and the re-calculation of
the CHS from the LBA depending on the geometry of the disk,
I have selected the former. At least it goes faster when
loading data from disk.
Etienne.
------------------------------
From: [EMAIL PROTECTED] (Jonas Persson)
Subject: The generic SCSI driver
Date: 11 Aug 1999 14:42:55 GMT
Hi linux users!
I recently began using a SCSI CD-recording device under linux, a
Matsushita CW 7502 to be exact. Everything works excellent, but
then I saw J�rg Schilling's notes on the Linux SCSI implementation
(for reference, see
http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/linuxscsi.html).
It seems like the interface is a little stupid in some aspects,
mainly that it cannot get the SCSI status byte. Apparantly
Douglas Gilbert solved this problem, but only partially. It
seems like the solution developed by J�rg Schilling and
Heiko Ei�feldt is better - but it was still rejected for
inclusion in kernel 2.2.x in favor for Douglas Gilberts solution.
Again, see the above mentioned webpage for details.
What are the plans for kernel 2.3.x? What is Linus and Alan's
view on this? And most importantly, why was an inferior solution
selected when a better one was available? As far as I can understand
from reading the mentioned page (and some kernel code, the sg device),
there are no disadvantages with Shilling's and Ei�feldt's solution.
I would be grateful if answers (if any! :-) are posted both to
the newsgroup and mailed to me.
Cheers,
Jonas Persson
Software Engineering Researcher
--
================================================================
Jonas Persson E-mail: [EMAIL PROTECTED]
Department of Computer Science Phone: +46-(0)46-222 9715
Lund Institute of Technology Cellular: +46-(0)707 79 36 55
Lund University Fax: +46-(0)46 13 10 21
Box 118 URL: http://www.cs.lth.se/
S-221 00 Lund
Sweden
================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Can a process be "out schedualed" while in a system call?
Date: Wed, 11 Aug 1999 14:57:13 GMT
If no here comes another question. In a charter device driver this was
in the read function:
while(lock & 0xBF ==0);
If the contdition was true this would go on forever, right?
Another question:
What do the cli()/sti() pair do? disable intrerupts?
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Device driver programming
Date: Wed, 11 Aug 1999 15:57:57 GMT
On Wed, 11 Aug 1999 11:18:26 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Hi,
> I am new to Red hat Linux...Even though I have done device drivers
>for NT and some embedded systems.. I am trying to write a dummy device
>driver....Can somebody point to resources that can help me
A great proportion of the kernel source code consists of device drivers, so
there is no shortage of example code. Find a driver that is closest to what you
want to do and then make something similar.
------------------------------
From: [EMAIL PROTECTED] (Stuart R. Fuller)
Subject: Re: how to tell a process is background?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 11 Aug 1999 16:10:01 GMT
Yung-Hsiang Lu ([EMAIL PROTECTED]) wrote:
: Hi, Everyone,
:
: I am curious whether there is a way to tell if a process is running at
: the background and does not interact with users (directly). I did not
: find anything in "task_struct" (sched.h) that seems able to tell me
: the information. I think priority won't do the job because top shows
: that quite a few processes have the same priority; some of them are
: background while the others are interactive.
Well, if a process does not interact with users directly, then it probably
doesn't have a channel open to "stdin", or its "stdin" isn't a terminal.
Looking at /proc/<process-id>/fd gives a list of all the open channels for
that process, and they are effectively links to files in the /dev directory.
So, I suppose you could look at the fd directory in /proc/<process-id> to see
if it has an open channel 0, and if so, does it point to a character device.
Failing that, you might want to indicate what problem you're trying solve.
Stu
------------------------------
From: Vyl Chan <[EMAIL PROTECTED]>
Subject: rc.local or command line
Date: Wed, 11 Aug 1999 11:00:10 -0700
Hi,
I'm having some trouble running a script that runs perfectly from
the command line but doesn't run completely from rc.local. What is the
difference between invoking a script from the command line and invoking
from the rc.local??
--Vyl
Vyl Chan
Stanford University
------------------------------
From: Steven J Haeck <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Sockets, FIOASYNC etc. AAAAAAAGh!
Date: 11 Aug 1999 19:28:25 +0100
> Please can anyone offer some assistance. I require to use the
> FIOASYNC ioctl in order to ensure that I get IO signals on a UDP
> socket. While I get no error returned, I also get no signals.
>
> I am aware that this has been a recent issue with the Linux kernel,
> but as I understand from linuxhq.com, " FIOASYNC (O_SYNC) IOCTL
> support" was fixed in version 2.2.5. I run redhat 6.0, and
> uname -a replies
>
> Linux hagal.dcs.ed.ac.uk 2.2.5-15 ...
I've resolved this problem now - I was using a SIOCGPGRP ioctl to set
my process to receive signals, whereas it appears I should have been
using the fcntl F_SETOWN. I am still somewhat surprised that I got no
error returned from this inappropriate ioctl (which works fine on
Solaris).
Now I'm trying to get a direct handle on the file descriptor which
caused the IO signal using the fcntl F_SETSIG and SA_SIGINFO argument
to sigaction. Alas, I get no new arguments to my signal handler -
contrary to what "man fcntl" says I should. Is it relevant that I had
to #define __USE_GNU to get at F_SETSIG.
I have read that I should use a real-time signal (>32) to make use of
SA_SIGINFO, and also that I don't need to. Neither seems to make any
difference. A similar question to last time - does anyone use
this facility? Which "gotcha" have I fallen foul of this time?
--
Steven J Haeck
Tel. : 0131-650-5165 Email : [EMAIL PROTECTED]
Fax. : 0131-667-7209 WWW : http://www.dcs.ed.ac.uk/home/sjh
------------------------------
From: Neil Koozer <[EMAIL PROTECTED]>
Subject: Re: My first linux program: non-bios boot loader
Date: Wed, 11 Aug 1999 09:24:53 +0000
> Saying EBIOS is irrelevant is like saying SCSI is irrelevant. In
> fact, they're pretty much equivalent, since EBIOS is the only option
> for getting non-IDE drives to work above cyl. 1024
I didn't realize that EBIOS could fix all those cards with on-board bios that
predates ebios.
> (unless you want to
> have a boot loader for each single SCSI card.)
It would have been fun to do 20 or 30 of these, but then again the testing
would be difficult without the hardware.
> I have to say I'm mighty impressed of the feat of writing an IDE
> driver that tiny.
Thank you. Most of the size though isn't the IDE stuff. For example, it
took many bytes to enable A20, which could be eliminated by loading the
kernel at 110000 instead of 100000. My first working prototype was 84 bytes,
which used a sector map implanted by (a hypothetically modified) lilo.
> I will certainly see if I can include it into lbcon;
I don't know what lbcon is. If you reuse the code be alert for places where
I only loaded a piece of a register and depended on the high bits being zero
already, for example:
mov cl, something ;may be really using ecx
Also, there is only one cld in the program since there are no calls to
anything outside.
> note, however, that I consider it a critical feature to make
> the decision at boot time -- not install time -- in order to survive
> jumps between machines, etc.
You mean putting the drive in another computer and booting it? Something
would have to install the loader, or are we always assuming hda?
Neil.
------------------------------
From: Neil Koozer <[EMAIL PROTECTED]>
Subject: Re: My first linux program: non-bios boot loader
Date: Wed, 11 Aug 1999 09:34:37 +0000
> [...]
> it may no longer boot. In lbcon I'm doing this determination at boot
> time rather than install time for these reasons. The problem, of
> course, is that one has to *really* shoehorn stuff into the boot
> block...
What about using the other 62 sectors in that initial track? The
current partitioning scheme doesn't use that (as far as I can tell).
Even other partitions, including logical partitions, skip over 63
sectors.
One could do a really capable loader using that much space, and the boot
sector code could always find it.
Neil.
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: My first linux program: non-bios boot loader
Date: 10 Aug 1999 21:57:08 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: Neil Koozer <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> The problem is:
> Many first-time installers of linux are blocked or frustrated by the
> "LI" or the "L 01 01 01..." problem.
> The latter is due to the bios being unable to address drives hdc-hdh or
> the bios being unable to address above cylindar 1023. The "LI" is
> usually due to geometry confusion between the bios and linux.
>
> The solution:
> Provide a no-fuss, no-muss alternative boot loader which:
> (1) boots linux from hda-hdh (ok scsi would be nice too)
> (2) boots linux from partition above 8gb
> (3) works with legacy hardware
> (4) loads bzImage as well as zImage
> (5) eliminates use of CHS geometry
>
> Since linux must be installed on pre-existing hardware, EBIOS is
> irrelavant. In fact the use of lagacy hardware is a selling point of
> linux.
>
Saying EBIOS is irrelevant is like saying SCSI is irrelevant. In
fact, they're pretty much equivalent, since EBIOS is the only option
for getting non-IDE drives to work above cyl. 1024 (unless you want to
have a boot loader for each single SCSI card.)
I have to say I'm mighty impressed of the feat of writing an IDE
driver that tiny. I will certainly see if I can include it into
lbcon; note, however, that I consider it a critical feature to make
the decision at boot time -- not install time -- in order to survive
jumps between machines, etc.
> p.s. I have not included scsi drives because I can not locate the
> programming docs for any scsi cards. Not even one. Can anyone point me
> in the right direction? The scsi standards only mention the interface
> amoung scsi devices; it doesn't mention the interface between the
> computer and the card.
There isn't one. Each card is different.
> p.p.s If we could add scsi, we could boot from "non-bootable" scsi
> cards.
See above.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
