Linux-Development-Sys Digest #237, Volume #8 Thu, 26 Oct 00 12:13:08 EDT
Contents:
Re: porting from SCO to linux problems? (Warren Young)
Re: makefile ("Paul D. Smith")
Kernel programming ([EMAIL PROTECTED])
Re: makefile (Jeff Andre)
Re: using /linuxrc (Josef Moellers)
Re: using /linuxrc (Josef Moellers)
Warning: Ignoring changed section attributes for .modinfo ("O.Petzold")
Re: ModSSL/Linux 6.1/Apache (Michel Talon)
Re: Microsoft Linux API? (Nix)
Re: advice needed on process hierarchies (Nix)
(Urgent) Linux-on-PowerPC Assemblers (Stack Offset)
Re: advice needed on process hierarchies (Alexander Viro)
Re: (Urgent) Linux-on-PowerPC Assemblers (nathan wagner)
Get inet6 address of an interface ? ([EMAIL PROTECTED])
msgsnd seems to be corrupting memory. (Marc Schneider)
Predictability of Pipe/Fcntl (Alexander Burger)
----------------------------------------------------------------------------
Date: Wed, 25 Oct 2000 20:04:50 -0600
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: porting from SCO to linux problems?
Martin Collins wrote:
>
> Does anybody have any experience in this line and can
> point out possible sources of difficulty. I'm supposed to
> estimate the effort invloved.
If you've never done this sort of work, you have no basis for making any
estimates, and since those of us who have done this kind of work haven't
seen the code, we can't make any estimates for you, either.
Having said that, you should probably just try to compile the program.
For everything that breaks, comment out the function body and build
again. When the whole thing builds and links, you will be able to count
the "#if 0"'s in the code to find out how much work you have to make all
those functions compile.
Once you've got the whole thing building, it probably won't take much
more work to make it run properly, but there will almost certainly be
_some_ of this work. (Path dependencies, slight system call semantics
differences, etc.)
FWIW, I ported 30,000 lines of code from SCO UnixWare to Linux in about
a week once. The main difference was that the UnixWare stuff used TLI
and not sockets. Once I'd ported it to sockets, I was able to back-port
to UnixWare again fairly easily.
Some general advice: every time you port to a new platform, try to make
the code more flexible than before. Eventually, ports become almost
trivial. Look at all the database vendors (Oracle, Borland, IBM,
Sybase...) who ported all their products in a matter of weeks. Their
products already ran on half a dozen platforms or more each, so moving
to one more was easy.
Also, get yourself a Stevens library. I recommend at least "Advanced
Programming in the Unix Environment" and "Unix Network Programming"
(both volumes). You can skip "TCP/IP Illustrated" for the moment. :)
--
= Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: makefile
Date: 25 Oct 2000 22:13:35 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Jeff Andre) writes:
ja> ifndef PLATFORM
ja> PLATFORM := $(shell uname -s)
ja> endif
If you then "export PLATFORM", you can avoid re-doing the uname in every
submake.
ja> ifneq ($(findstring $(PLATFORM),linux Linux LINUX),)
ja> override PLATFORM := linux
ja> endif
ja> ifneq ($(findstring $(PLATFORM),sunos SunOS SUNOS solaris Solaris SOLARIS),)
ja> override PLATFORM := solaris
ja> endif
I think "uname" on every Linux system returns "Linux", with that
capitalization, and likewise I've never seen any Sun system where
"uname" didn't return "SunOS", so I don't think those findstring
functions are necessary.
Also, do you really want to use override here? If you do, then users
can't change the value of PLATFORM on the command line.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED]
Subject: Kernel programming
Date: Thu, 26 Oct 2000 10:20:04 +0800
Hello everyone,
I am a beginner in kernel programming in Linux. Would like to ask
some questions.
1) Where can I get some information about function calls that can be used
in kernel, like printk, fprintk,....
2) Suppose I want to print something in kernel, where does it output to?
Thank you very much!
Regards,
Hung
------------------------------
From: [EMAIL PROTECTED] (Jeff Andre)
Subject: Re: makefile
Date: 26 Oct 2000 03:17:23 GMT
Paul D. Smith ([EMAIL PROTECTED]) wrote:
: %% [EMAIL PROTECTED] (Jeff Andre) writes:
: ja> ifndef PLATFORM
: ja> PLATFORM := $(shell uname -s)
: ja> endif
: If you then "export PLATFORM", you can avoid re-doing the uname in every
: submake.
Cool, should do that.
The other reason it's specified early in the common make rules is if
the developer forgets/doesn't specify it on the command line. If
that case, we assume they wanted to build for the platform they're on.
: ja> ifneq ($(findstring $(PLATFORM),linux Linux LINUX),)
: ja> override PLATFORM := linux
: ja> endif
: ja> ifneq ($(findstring $(PLATFORM),sunos SunOS SUNOS solaris Solaris
:SOLARIS),)
: ja> override PLATFORM := solaris
: ja> endif
: I think "uname" on every Linux system returns "Linux", with that
: capitalization, and likewise I've never seen any Sun system where
: "uname" didn't return "SunOS", so I don't think those findstring
: functions are necessary.
We do that because some developers are not as careful as they
should be when they specify the PLATFORM on the command line. I
got tired to dealing with 'the build doesn't work' and got aggressive.
: Also, do you really want to use override here? If you do, then users
: can't change the value of PLATFORM on the command line.
In our build we use that variable in a number of places besides the
include of the platform specific rules so it helps to make sure it's
normalized to a standard value. Related to the point above.
Jeff Andre
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: using /linuxrc
Date: Thu, 26 Oct 2000 08:44:12 +0200
[EMAIL PROTECTED] wrote:
> =
> On Wed, 25 Oct 2000 08:47:38 +0200 Josef Moellers <josef.moellers@fujit=
su-siemens.com> wrote:
> =
> | Yeppp, an installed RedHat7.0 has an initrd with /linuxrc being a she=
ll
> | script:
> |
> | #!/bin/sash
> |
> | aliasall
> |
> | echo "Loading sym53c8xx module"
> | insmod /lib/sym53c8xx.o
> | echo "Loading qla2x00 module"
> | insmod /lib/qla2x00.o
> |
> | So, what I'd like to do is insert something like
> | case `bootcontroller` of
> | aic*) echo "loading aic7xxx module"; insmod /lib/aic7xxx.o;;
> | sym*) echo "loading sym53c8xx module"; insmod /lib/sym53c8xx.o;=
;
> | esac
> =
> I guess the probing process is complex enough that they only do so at
> install time because of the problems it could encounter, such as the
> time it takes, etc.
> =
> What is this "bootcontroller" program? Your prober?
Yes, it will be reading DMI (Desktop Management Information) data which
contains, among other things, a string describing the on-board
SCSI-hostadapter (if any). If I restricted the supported configurations
to those which have the boot disk on an on-board adapter, I could
determine which driver to load first.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: using /linuxrc
Date: Thu, 26 Oct 2000 08:53:47 +0200
[EMAIL PROTECTED] wrote:
> =
> On Wed, 25 Oct 2000 08:33:10 +0200 Josef Moellers <josef.moellers@fujit=
su-siemens.com> wrote:
> =
> | Mee too mee too, I need to determine what the on-board SCSI hostadapt=
er
> | is, in order to load the driver to handle it, presuming that the boot=
> | disk is conected to it. Since it may very well be an aic7xxx based
> | adapter and the customer also has a sym53c8xx based PCI card and vice=
> | versa, loading either driver first will fail in one setup or the othe=
r.
> =
> If the set of driver choices is finite, you could in theory compile the=
m
> into the kernel. But I'm assuming you have some reason to use modules,=
> such as a vast range of SCSI possibilities. You're /linuxrc will have =
to
> do the probing, I assume.
Well, compiling them into the kernel would imply a fixed sequence of
probing.
Our different models have different SCSI hostadapters. If I compiled the
drivers into the kernel, an Adaptec hostadapter in a PCI slot would be
probed before an on-board SymBIOS/LSILogic hostadapter. If both HAs had
disks, the root disk (presumably on the SymBIOS/LSILogic) will not be
recognized as /dev/sda.
Therefore I need some means to determine the SCSI infrastructure.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: "O.Petzold" <[EMAIL PROTECTED]>
Subject: Warning: Ignoring changed section attributes for .modinfo
Date: Thu, 26 Oct 2000 08:53:23 +0200
Hello,
if I compile my kernel module, I get the follwing error
gcc -DHAVE_CONFIG_H -I. [...] -D__KERNEL__ -DMODULE -c mod.c
/tmp/ccPuc1p2.s: Assembler messages:
/tmp/ccPuc1p2.s:9: Warning: Ignoring changed section attributes for
.modinfo
what does it mean?
# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
Thanks Olaf
------------------------------
From: Michel Talon <[EMAIL PROTECTED]>
Subject: Re: ModSSL/Linux 6.1/Apache
Date: Thu, 26 Oct 2000 09:29:11 +0200
Fabien Voland <[EMAIL PROTECTED]> wrote:
> En date du Wed, 25 Oct 2000 18:39:35 GMT, de [EMAIL PROTECTED]
> (Kaz Kylheku), a �crit:
>>On Wed, 25 Oct 2000 18:34:54 GMT, Fabien Voland <[EMAIL PROTECTED]> wrote:
>>>Hi, thanks for your answer.
>>>
>>>En date du Wed, 25 Oct 2000 16:05:05 +0200, de
>>>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, a �crit:
>>>
>>>>Hi,
>>>>
>>>>It is best to compile from source,
>>>
>>>Can you tell me why ? (I'm novice in Redhat 6.1).
>>
>>Because if you compile the source code, then the resulting executable will be
>>perfectly matched to the versions of libraries you have on your system. People
>>who compile their own binaries are strangers to shared library versioning
>>headaches.
> Ok, thanks. But just a question : between the version of Apache
> distribued with Redhat and the source code only of Apache, is it a
> difference ?
Download the RedHat RPMS (source) and you will find the patches they have
applied. Frequently, very minor ones, purely cosmetic.
Compiling from source implies compiling with your libraries (no need to get
10 versions of the same lib) and being able to put compiler optimizations you
like. RedHat has to use most conservative options so that it runs on all
machines. Plus you can install where you like.
> Thanks.
> Fabien
> ----------------------------------------------------
> From Anywhere
> ----------------------------------------------------
--
Michel Talon
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Microsoft Linux API?
Date: 26 Oct 2000 00:01:54 +0100
"Brandon Van Every" <[EMAIL PROTECTED]> writes:
> That's true today. As Linux grows, you will have more and more people
> who could care less about the source code and just want the job to get
> done reliably. If you posit a Linux world where all Linuxen insist on
> source code, you are positing a Linux world that cannot grow. The
> market for developer hackers is only so big.
And why should those of us on comp.os.linux.development.system care a
whit for this set of non-developers?
I know I don't. If someone doesn't develop, document, help out on
newsgroups, or in some way contribute to the community, then I don't
care if they're using Linux; they could be using a mechanical typewriter
for all I care.
--
`Normally, we don't do people's homework around here, but Venice
is a very beautiful city, so I'll make a small exception.'
--- Robert Redelmeier compromises his principles
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: advice needed on process hierarchies
Date: 26 Oct 2000 00:06:23 +0100
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <8t342a$9v7$[EMAIL PROTECTED]>,
> Richard Lim <[EMAIL PROTECTED]> wrote:
> >Advice needed on the following:
>
> [snip the homework assignment]
>
> >please advice on the solution.
> >I am not able to derive a solution for this one.
> >Is there a simple algorithms to follow to generate the C code to create the
> >process hierarchy of any kind.
>
> comp.unix.do.my.homework is -> that way. Alternatively, you could try
> to read the manpage of fork() and think for a couple of minutes.
It's a bloody useless assignment, too; nobody calls fork() and then
keeps going down the same path they left, so this assignment isn't even
teaching a common idiom.
I diagnose `Crap Course Syndrome'... although compared to the C course I
saw once that suggested using chars rather than ints wherever possible
because `there are fewer bits to manipulate so it is faster'...
Most training courses are just GIGO in action, I think.
--
`Normally, we don't do people's homework around here, but Venice
is a very beautiful city, so I'll make a small exception.'
--- Robert Redelmeier compromises his principles
------------------------------
Date: Thu, 26 Oct 2000 06:12:19 -0400
From: [EMAIL PROTECTED] (Stack Offset)
Subject: (Urgent) Linux-on-PowerPC Assemblers
Crossposted-To:
comp.os.linux.powerpc,comp.os.linux.misc,de.comp.os.unix.linux.misc,no.it.os.unix.linux.diverse,uk.comp.os.linux
Please respond to this by e-mail *only* : I do not ordinarily browse internet
newsgroups.
I'm seeking SPECIFIC product/manufacturer information on all known assemblers
which are available for Linux running on PowerPC systems affiliated to the
following
*IBM
*Motorola
*Apple
*Amiga
*Macintosh clones
*Tivo
*Synergy Microsystems
*Embedded Planet, Bright Star Engineering
*(OTHERS KNOWN TO THE PUBLIC)
Anyone having SPECIFIC information on the identity(-ies) of one/more of such
Linux-on-PowerPC assembler(s) or its/their manufacturer(s) may please e-mail
me with the information.
Thanks.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: advice needed on process hierarchies
Date: 26 Oct 2000 07:20:23 -0400
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> wrote:
>[EMAIL PROTECTED] (Alexander Viro) writes:
>
>> In article <8t342a$9v7$[EMAIL PROTECTED]>,
>> Richard Lim <[EMAIL PROTECTED]> wrote:
>> >Advice needed on the following:
>>
>> [snip the homework assignment]
>>
>> >please advice on the solution.
>> >I am not able to derive a solution for this one.
>> >Is there a simple algorithms to follow to generate the C code to create the
>> >process hierarchy of any kind.
>>
>> comp.unix.do.my.homework is -> that way. Alternatively, you could try
>> to read the manpage of fork() and think for a couple of minutes.
>
>It's a bloody useless assignment, too; nobody calls fork() and then
>keeps going down the same path they left, so this assignment isn't even
>teaching a common idiom.
Look at it that way: if you ask a common luser WTF fork() does he will just
mumble BS. However, luser with a cheatsheet _will_ spout a correct answer.
That's where you hit him with a trivial question that requires two things:
posessing the answer to original one _and_ a couple of working neurons.
Works like charm. Especially if you are into torturing those who believe
that they can learn without thinking. Or pass without learning...
<b,ng>
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (nathan wagner)
Crossposted-To:
comp.os.linux.powerpc,comp.os.linux.misc,de.comp.os.unix.linux.misc,no.it.os.unix.linux.diverse,uk.comp.os.linux
Subject: Re: (Urgent) Linux-on-PowerPC Assemblers
Date: 26 Oct 2000 13:44:44 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 26 Oct 2000 06:12:19 -0400,
Stack Offset <[EMAIL PROTECTED]> wrote:
>Please respond to this by e-mail *only* : I do not ordinarily browse internet
>newsgroups.
Post it here, read it here. We're not your personal research assistant.
*plonk*
--
Chance is irrelevant. We will succeed. -- Seven of Nine
------------------------------
From: [EMAIL PROTECTED]
Subject: Get inet6 address of an interface ?
Date: Thu, 26 Oct 2000 14:10:26 GMT
Hi all,
We are developing a link layer network driver in a linux loadable
module on kernel 2.2.14.
We need to get the IPv4 and IPv6 addresses of this driver interface,
from inside our module code.
For IPv4, we've used devinet_ioctl (SIOCGIFADDR, struct ifreq *) with
ifr_name set to our interface name and it works well.
For IPv6, there is no similar function. We've seen in the kernel code
the function ipv6_get_lladdr called by ndisc but it's not an exported
symbol.
Any idea ?
Thanks for help,
Sylvie
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Marc Schneider <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: msgsnd seems to be corrupting memory.
Date: Thu, 26 Oct 2000 14:47:58 GMT
msgsnd seems to be corrupting memory around the msgbuf pointer.
for example I have the following code:
pMsgBuf = malloc(iPacketLen + 4 + 8);
bzero(pMsgBuf, iPacketLen + 4 + 8);
pMsgBuf += 4; /* Build a guard band */
printf("PMQ:pMsgBuf: %p\n",pMsgBuf);
printf("PMQ:-4: %p\n", *(pMsgBuf-4));
rc = msgsnd(iMsgQueueID, pMsgBuf, iPacketLen, 0);
printf("AMQ:pMsgBuf: %p\n",pMsgBuf);
printf("AMQ:-4: %p\n", *(pMsgBuf-4));
results in the following output:
PMQ:pMsgBuf: 0x8067424
PMQ:-4: (nil)
AMQ:pMsgBuf: 0x8067424
AMQ:-4: 0x3
clearly, AMQ:-4 should print (nil).
Any ideas as to what could be going wrong?
I'm am running a stock Redhat 6.1 system, kernel 2.2.14 I believe.
This is also causing a segmentation fault.
Marc
------------------------------
From: Alexander Burger <[EMAIL PROTECTED]>
Subject: Predictability of Pipe/Fcntl
Date: Thu, 26 Oct 2000 17:28:34 +0200
I posted the following to comp.os.linux.development.apps nearly one week
ago, but didn't get ANY response. Perhaps it was the wrong group, or
perhaps my news feed isn't working. So here I try again, this time in the
system's group:
Are data sent through a pipe immediately available to other processes (when
they are running the next time), or may it take some time to pass through
the kernel?
I have a server process spawning a number of child processes. The children
are connected by pipes to each other, and operate on a common database
file. When a child process modifies the database, it obtains a write-lock
with fcntl() on the file, and starts to modify it. During these
modifications, some messages are sent through the pipes. Finally, the lock
on the file is released.
Before another process can also modify the file, it must be guaranteed that
it received all piped messages from previous modifications. Currently, each
process does the following:
1. Lock database
while (somebody has locked the file)
sleep a little
check the pipe for incoming data
2. Be sure to read all incoming data
while (pipe data available)
read them
3. Modify database
write records
send outgoing messages
4. Unlock database
Everything works fine so far, and I observed no glitches. However, can I be
sure that it functions under all circumstances?
For example, what if the pipe data take longer through the kernel than the
"unlock"-information? Step 2 would not receive all piped data from other
processes before it starts the modifications in step 3.
I could insert a sleep() before step 2, but that's a kludge.
Ideally, I would like to have the guarantee that both fcntl()-changes and
pipe transmissions take effect immediately (and in the same sequence) after
they are issued. Does anybody know anything about that?
Any comments welcome!
Cheers,
- Alex
------------------------------
** 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
******************************
