Linux-Development-Sys Digest #232, Volume #6 Thu, 7 Jan 99 15:14:12 EST
Contents:
Tuning Semaphores and Shared Memory parameters in Slackware Linux 2.0.35 ("Sudhir
Nelvagal")
Re: iBCS? (Michael Engel)
Re: "soft" power button and linux (Kenneth Crudup)
Re: GUI, The Next Generation (Michael Kelly)
Re: Printing broke with 2.2.0-pre4 (Grahame M. Kelly)
TCP/IP timeout bug (Jeff Thompson)
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: Registry for Linux - Bad idea (Richard RUDEK)
Re: Registry for Linux - Bad idea ("Frederick W. Reimer,Sr")
Re: subscribe (Rik van Riel)
Re: 2.2.0-pre5 problem with ip_masq.c ("Harry")
----------------------------------------------------------------------------
From: "Sudhir Nelvagal" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.development.apps
Subject: Tuning Semaphores and Shared Memory parameters in Slackware Linux 2.0.35
Date: Wed, 6 Jan 1999 16:34:05 -0500
Folks:
Is there a way for me to modify some of the kernel parameters like
number of semaphores and shared memory segments. My program requires higher
number of semaphores than what is offered by the system. I am running
Slackware Linux 2.0.35.
Is there a tool like HP's SAM or AIX's SMIT to enable doing such things.
I found some #defines in asm/sem.h or someplace where some of the parameters
like SEMMNI etc were defined. Is this used by the kernel code in order to
set these values?
Anyways, If somebody out there can tell me how to modify Semaphore and
Shared Memory parameters and if a manual re-compilation of the kernel is
required, the procedure to do it, I will be most grateful
Sudhir
[EMAIL PROTECTED]
------------------------------
From: Michael Engel <[EMAIL PROTECTED]>
Subject: Re: iBCS?
Date: 6 Jan 99 21:38:43 GMT
JAD <[EMAIL PROTECTED]> wrote:
: Last I looked into the iBCS matter I a little surprised to
: find that nothing seemed to have happened since 1994(?)
: Is that really so?
I don't think so - the latest version of iBCS I found is
ibcs-2.1-981105.tar.gz which works quite nicely for me.
You have support for a.out, ELF, COFF and XOUT binary formats on intel
and additional support on Sparc (Solaris emulation).
: I was looking for a way to execute programs made for
: Solaris 7 (Intel) under Linux, but I'm not sure about what
: I found. Does anybody have any experience?
Not with Solaris/intel, sorry. There is Solaris/Sparc emulation support
on Sparcs and SVR4 emulation support on intel ... just give it a try ...
: Also I wondered if there is support for AIX programs (for
: Intel CPUs)?
You're really thinking of AIX 1.3 for intel ? Whow, _that's_ tough !
Maybe a generic SVR3 emulation may work. AFAIR AIX 1.3 doesn't support
shared libraries, so you might have a chance. Hmmm, AIX 1.3 is the only
proper OS (except for Minix maybe) that runs on my PS/2 Model 55SX ;-).
regards,
Michael Engel ([EMAIL PROTECTED])
A
A
A
A
A
A
A
A
A
------------------------------
From: [EMAIL PROTECTED] (Kenneth Crudup)
Crossposted-To: comp.os.linux.hardware
Subject: Re: "soft" power button and linux
Date: 7 Jan 1999 09:48:41 -0500
In article <770a93$95b$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kirk Johnson) says:
>i'm trying to determine if there's any way i can "catch" somebody
>pressing the "soft power button" on the front of my linux box and
>handle it in software -- specifically, what i'm looking for is a way
>to have linux execute a graceful shutdown when somebody presses the
>power button.
If the "soft power button" doesn't create an event Linux can get a hold of,
there's nothing Linux can do. Can you set it in your BIOS to make the power
switch become a "suspend" switch? If so, then you can use that with the
"apmd" utility to get a sucessful shutdown.
-Kenny
--
Kenneth R. Crudup, Unix Software Consultant, Scott County Consulting
Home: | Purgatory:
8811 Colesville Rd., #509 | P.O. Box 230009 301-562-1922(H)
Silver Spring, MD 20910 | Boston, MA 02123-0009 617-422-2443(W)
------------------------------
From: [EMAIL PROTECTED] (Michael Kelly)
Subject: Re: GUI, The Next Generation
Date: Wed, 06 Jan 1999 17:56:51 -0500
On Mon, 04 Jan 1999 05:27:26 +0000, mlw <[EMAIL PROTECTED]> wrote:
>Ken Sorensen wrote:
>> Questions to Ask:
>> 1. Why do apps need to be in overlapping windows?
>> 2. Why does it have to be flag (not 3D)?
>> 3. Why do we need a Mouse (or keyboard - it may be obvious but think about
>> it...)?
Hmm, funny you should mention it but I was just watching
"Godzilla v. Monster Zero" and the cats from Planet X
programmed their computers directly using brainwaves.
Tough to beat *that* for a user interface! Now all that
remains is the implementation! :-)
Mike
"Genius gives birth, talent delivers."
- Jack Kerouac
(remove NOSPAM from address, if present, to reply)
------------------------------
From: [EMAIL PROTECTED] (Grahame M. Kelly)
Subject: Re: Printing broke with 2.2.0-pre4
Date: 6 Jan 1999 22:13:01 GMT
David Ronis <[EMAIL PROTECTED]> writes:
> I'm upgrading from 2.0.36 to 2.2.0-pre4 on an i486 with a postscript
> printer connected to its parallel port. I'm now at the point where printing
> a file causes the printer display to flash, but still nothing is printed.
>
> Here's my setup:
>
> crw-rw-rw- 1 root daemon 6, 0 Jan 5 20:39 /dev/lp0
> crw-rw-rw- 1 root daemon 6, 1 Jan 5 20:42 /dev/lp1
> crw-rw-rw- 1 root daemon 6, 2 Jan 5 20:42 /dev/lp2
> crw-rw-rw- 1 root daemon 99, 0 Jan 5 20:46 /dev/parport0
> crw-rw-r-- 1 root daemon 99, 1 Jan 5 20:48 /dev/parport1
> crw-rw-r-- 1 root daemon 99, 2 Jan 5 20:48 /dev/parport2
>
> Lp was set up as a module in the kernel:
>
> CONFIG_PRINTER=m
> CONFIG_PRINTER_READBACK=y
>
> and I have the following in my conf.modules:
>
> alias parport_lowlevel parport_pc
>
> The messages file shows:
>
> Jan 5 22:17:00 kirkwood kernel: parport0: no IEEE-1284 device present.
> Jan 5 22:17:00 kirkwood kernel: lp0: using parport0 (polling).
>
> I tried changing the setting in /etc/printcap to use /dev/parport0 directly,
> but this didn't work either.
>
> David Ronis
>
> P.S., in case you're wondering, the printer worked under 2.0.36, the
> only change being to replace /dev/lp1 by /dev/lp0 in printcap.
I confirm the same problem. In /proc/parport/ both on my ./0 ./1 printers
autoprobe doesn't find the printer info that is found in 2.2.0pre3.
Unknown reasons, I guess the problem is in the parport routine.
Grahame.
--
Member Sydeny Linux Users Group (SLUG)
Website = http://www.slug.org.au
Mailing List = slug (AT) slug (DOT) org (DOT) au
AntiSpamming enabled.
REAL email address is => gmkelly (AT) zip (DOT) com (DOT) au
------------------------------
From: Jeff Thompson <[EMAIL PROTECTED]>
Subject: TCP/IP timeout bug
Date: 07 Jan 1999 10:39:44 -0800
Hello. There was a discussion on comp.mail.sendmail (included below)
which concluded that there is a problem somewhere in the TCP/IP
connection to Sun machines, perhaps involving timeouts on packets with
repeated characters. The effect is a broken connection. Is this a
known bug and are there recommended ways of fixing it?
Any help appreciated,
- Jeff
===============
>From: [EMAIL PROTECTED]
Subject: Re: collect: I/O error
I looked into this and decided there is a TCP/IP problem between Linux and
(?), certainly Sun in my case. I was able to make other services fail, even
FTP and TELNET, if a packet had too many repeated characters. Even typing:
AAAAAAAAAAAA.... for a few hundred bytes, would TOTALLY LOCK UP THE
CONNECTION!
I found that a workaround was to lower the MTU/MRU of my PPP connection to
296, that way the packets are too small to trigger the bug!
I don't know if it is a Sun bug or a Linux bug. But, it is definitely a
TCP/IP problem (not PPP- other connections were still up, only the connection
with the repeated bytes went down), not a sendmail problem.
...
If I have my MTU/MRU at 1500, and sendmail, *or FTP*, *or TELNET*, transfers:
AAAAAAAAAAAAAAAAAAAA.... (lines with just "A"s) (for over about 500-600 bytes)
from Linux to Sun, it works, from Sun to Linux- *DEAD CONNECTION* !!!
I can reproduce this consistently. Linux 2.0.36, SunOS 5.6. It does not fail
Sun<->Sun or Linux<->Linux.
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 06 Jan 1999 09:12:47 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> Could you give us a brief description of CODA, I am not familair
> with it,
a pretty advanced network filesystem loosly based on AFS with very
aggressive client-side caching, among other nifty features.
http://coda.cs.cmu.edu/ has the full story.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Obviously I was either onto something, or on something.
-- Larry Wall on the creation of Perl
------------------------------
From: [EMAIL PROTECTED] (Richard RUDEK)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sat, 02 Jan 1999 07:23:04 GMT
"Frederick W. Reimer,Sr" <[EMAIL PROTECTED]> wrote:
>It's the same effect (as a registry). The point is that all
>configuration data is stored through the same mechanism, if not in the
>same file/database/registry. This stifles innovation and creativity.
You mean like not changing the way a program configures itself (if it aint
broke, don fix it) ; having to cut and paste code from another program
which already parses a text configuration file, worrying about stuff that
should be available in a standard library instead of getting on with the
program...
>There are just some programs, such as sendmail, that can't make due with
>a "standard" configuration scheme. I've seen some programs where the
>configuration was part of the actual program (because it was in perl a
>user would modify a file written in perl that would be executed from the
>main program to setup things).
I wasn't suggesting configuration options had to be changed in the source,
but carry on.
>
>While I suppose it would be possible to use your scheme and have
>different files, it naturally suggests a single file, database, or
>(cough) registry.
I agree, a registry for linux is a bad idea. But I don't see how a standard
configuration procedure "naturally suggests a single file". Even if you
take Windows as an example, before NT and Win95, the Standard configuration
procedure didn't use a registry - they used INI files. OK, I'm not
suggesting we go that way (no WIN.INI thanks). But the point is that there
is one defined way to do this, which can be secured and re-implemented as
required, without change to (compatible) code. If well designed, you would
allow applications that have special requirements to operate in an abstract
way to achieve them - custom types, raw entries, readln()...
>...This is one of the major complaints of the registry -
>having all configuration in the same place. This presents a single
>point of failure. What happens if something crashes when the registry
>is being modified, even if it is in a text file? Depending on how that
>text file is being updated, there are a few possibilities. Databases,
>while offering more robustness, have another problem. One, and don't
>take this as a joke, there were hints that microsoft was planning on
>moving the registry to SNA Server. Give MS's track record, I'd just as
>soon stay away from databases all together as a configuration storage
>mechanism. But more specifically, you would be required to have a
>database on every box. A networked database would not due, as
>networking and bootup parameters would be some of the configuration data
>stored in said database. If it's not local, you cant get to the data to
>configure your computer to get to the database to get the data to
>configure your machine... ad infinitum. Second, the database would have
>to be part of the kernel, or VERY VERY close to it. What are some of
>the first programs to be run after the kernel is up? init may be? Well
>init currently has a text-based configuration file (/etc/inittab). So
>the database would have to be available BEFORE the very first process is
>created by the kernel, hence part of the kernel. I think this would be
>a catastrophic mistake to put a database in the Linux kernel. Ask
>anyone else, they would probably agree. So what are you going to do,
>start making exceptions so that SOME programs use existing configuration
>methods but others don't? That seems unreasonable and does not fit into
>your model very well.
Well, maybe your (linux's ?) definition of kernel is different to mine. But
sure, the configuration procedures would need to be available to init and
other startup routines (That's why I'm discussing it). But this is true of
anything that creates fundamental services - bootstrap for instance.
>...System configuration is one of the main areas
>that seem to be of concern (sendmail, POP3, users, groups, etc). If you
>don't have system configuration in your registry, why have one at all?
Huh ?
>
>I'd say the solution is to learn the systems and programs you wish to
>use instead of trying to force a system wide configuration model on each
>and every program in the world, destroying the Linux kernel while you
>are at it (if you go for the database storing method).
>
>An No, I don't think there is "a way to reduce the amount of effort and
>synchronicity needed to maintain configuration data, both in terms of
>documentation and operational maintenance."
Well if you don't try, you don't get anywhere.
>I think the answer is
>simply to hire the correct person for maintaining your systems.
Oh. status quo.
>...While
>anyone (almost) can flip burgers at the local fast food joint, there are
>relatively few who understand or can quickly and acurately figure out
>how to properly maintain a complex computer system.
You know, it's funny how you say flipping burgers can be done almost by
anyone, yet if you tried to make a robot to do that...
>... Once CIO's and
>other managers who have been brainwashed by Microsoft into thinking
>practically ANYONE can administer a system if they were given simple
>configuration tools realize the error of their ways we can all get back
>to the proper method of running IT systems.
But what about the home users - this is Linux we're talking about.
>
>I personally believe that the difficulty of configuring a system should
>be relatively equal to the complexity of said system. In other words,
>the configuration for sendmail BETTER be difficult, because the sendmail
>itself is a very complex system. You would not want to make it EASIER
>to configure because then you would run into the problem of entry level
>people trying to configure it and screwing everything up.
But my point would be, why is it so complex ? Can it be made easier ?
Not, it already works, so it must good ; Or that it's as complex as needs
to be.
>
>Leave systems configuration to the experts.
>
>Leave helpdesk tasks to entry-level "administrators."
Interesting. It's quite obvious your not interested in making computer
systems easier to administer, because it's already solved - that's how I
make my money, maybe ?. "ease" of administration does not necessarily
impart skill upon the operator. That's a given. But likewise, complex
systems don't either, and should be reviewed.
My suggestion was an *inital* attempt at *trying* to address issues with
home/single user configuration, but combining it with a fundamental system
change that, if designed/implemented correctly, *could* reduce the amount
of effort required by developers to achieve this. It would also formalise a
way to access configuration services, just like we have created standard
functions, libraries, etc.
You've raised some good points, things that do need to be discussed. But
the one thing I find most annoying though, is how you've tried to make the
suggestion what it's not - the subject change is deliberately divisive.
If you don't want things to change, fine. But real progress can only be
achieved by those that question fundamentals: Horse and buggy, dirt roads,
punch cards... :)
Anyway, the suggestion is out there, take it or leave it...
__ __ _______________________________
//)) //)) | Richard RUDEK. MicroDek. | Hey, it's Friday night...
//\\ //\\ | Chatswood, Sydney. Australia. | C:\WORK> CD \
`-------------------------------'
------------------------------
From: "Frederick W. Reimer,Sr" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sat, 02 Jan 1999 07:23:09 GMT
Richard RUDEK wrote:
>
> "Frederick W. Reimer,Sr" <[EMAIL PROTECTED]> wrote:
>
> >It's the same effect (as a registry). The point is that all
> >configuration data is stored through the same mechanism, if not in the
> >same file/database/registry. This stifles innovation and creativity.
>
> You mean like not changing the way a program configures itself (if it aint
> broke, don fix it) ; having to cut and paste code from another program
> which already parses a text configuration file, worrying about stuff that
> should be available in a standard library instead of getting on with the
> program...
No, like not forcing all the developers in the free software domain into
using the same limited configuration system that, even if agreed to by
the majority at the time, is dictated from on-high.
>
> >There are just some programs, such as sendmail, that can't make due with
> >a "standard" configuration scheme. I've seen some programs where the
> >configuration was part of the actual program (because it was in perl a
> >user would modify a file written in perl that would be executed from the
> >main program to setup things).
>
> I wasn't suggesting configuration options had to be changed in the source,
> but carry on.
Well, if you change the way configurations are stored and read, how
would you accomplish that other than modifying each and every OSS
package out there?
> >While I suppose it would be possible to use your scheme and have
> >different files, it naturally suggests a single file, database, or
> >(cough) registry.
>
> I agree, a registry for linux is a bad idea. But I don't see how a standard
> configuration procedure "naturally suggests a single file". Even if you
> take Windows as an example, before NT and Win95, the Standard configuration
> procedure didn't use a registry - they used INI files. OK, I'm not
> suggesting we go that way (no WIN.INI thanks). But the point is that there
> is one defined way to do this, which can be secured and re-implemented as
> required, without change to (compatible) code. If well designed, you would
> allow applications that have special requirements to operate in an abstract
> way to achieve them - custom types, raw entries, readln()...
I just don't think that changing just about every program in existance
that we have the source to is worth the effort. You'd be much more
productive to just learning how things are done instead of trying to
change them to some method that a simpleton could understand.
> >...This is one of the major complaints of the registry -
> >having all configuration in the same place. This presents a single
> >point of failure. What happens if something crashes when the registry
> >is being modified, even if it is in a text file? Depending on how that
> >text file is being updated, there are a few possibilities. Databases,
> >while offering more robustness, have another problem. One, and don't
> >take this as a joke, there were hints that microsoft was planning on
> >moving the registry to SNA Server. Give MS's track record, I'd just as
> >soon stay away from databases all together as a configuration storage
> >mechanism. But more specifically, you would be required to have a
> >database on every box. A networked database would not due, as
> >networking and bootup parameters would be some of the configuration data
> >stored in said database. If it's not local, you cant get to the data to
> >configure your computer to get to the database to get the data to
> >configure your machine... ad infinitum. Second, the database would have
> >to be part of the kernel, or VERY VERY close to it. What are some of
> >the first programs to be run after the kernel is up? init may be? Well
> >init currently has a text-based configuration file (/etc/inittab). So
> >the database would have to be available BEFORE the very first process is
> >created by the kernel, hence part of the kernel. I think this would be
> >a catastrophic mistake to put a database in the Linux kernel. Ask
> >anyone else, they would probably agree. So what are you going to do,
> >start making exceptions so that SOME programs use existing configuration
> >methods but others don't? That seems unreasonable and does not fit into
> >your model very well.
>
> Well, maybe your (linux's ?) definition of kernel is different to mine. But
> sure, the configuration procedures would need to be available to init and
> other startup routines (That's why I'm discussing it). But this is true of
> anything that creates fundamental services - bootstrap for instance.
The kernel, IMHO, should be limited to those areas concerned with
interfaces to the hardware and process control (i.e, tasks, "niceness",
etc).
> >...System configuration is one of the main areas
> >that seem to be of concern (sendmail, POP3, users, groups, etc). If you
> >don't have system configuration in your registry, why have one at all?
>
> Huh ?
Follow my above remarks, if the bootstrap programs, which is definately
part of the system configuration, don't have access to this registry
(because it is in all likelihood NEVER to be part of the kernel) then
where do you draw the line on what programs should have their configs in
the registry and not? sendmail and POP3 were mentioned, I believe, in
the original post as reasons why configuration of Linux systems are so
difficult.
> >
> >I'd say the solution is to learn the systems and programs you wish to
> >use instead of trying to force a system wide configuration model on each
> >and every program in the world, destroying the Linux kernel while you
> >are at it (if you go for the database storing method).
> >
> >An No, I don't think there is "a way to reduce the amount of effort and
> >synchronicity needed to maintain configuration data, both in terms of
> >documentation and operational maintenance."
>
> Well if you don't try, you don't get anywhere.
I have no need to get anywhere. I have no problem understanding complex
systems and configuring them properly.
> >I think the answer is
> >simply to hire the correct person for maintaining your systems.
>
> Oh. status quo.
I don't understand this. The status quo now is to hire people that are
UNqualified to maintain complex systems because administrators (managers
not computer administators) think that "anyone" can maintain a Windows
system. The "old" status quo was to hire those that are capable of
understanding complex systems and counting on them to figure out how
those systems interact and come up with the correct configuration. This
is what I propose.
> >...While
> >anyone (almost) can flip burgers at the local fast food joint, there are
> >relatively few who understand or can quickly and acurately figure out
> >how to properly maintain a complex computer system.
>
> You know, it's funny how you say flipping burgers can be done almost by
> anyone, yet if you tried to make a robot to do that...
A robot is not responsible for maintaining computer systems or flipping
burgers. If one is utilized, the person responsible for the robot is
ultimately responsible for it's productivity.
> >... Once CIO's and
> >other managers who have been brainwashed by Microsoft into thinking
> >practically ANYONE can administer a system if they were given simple
> >configuration tools realize the error of their ways we can all get back
> >to the proper method of running IT systems.
>
> But what about the home users - this is Linux we're talking about.
Yes, and Linux is not ready for the computer illiterate. I know your
response will be that you are proposing a system that would make it
ready, but I don't agree. I think that a slimed down version of Linux
with GUI configuration tools to modify the text based configuration
files would work quite well. Take Kppp for instance, it works as an
almost drop in for Windows DUN.
> >I personally believe that the difficulty of configuring a system should
> >be relatively equal to the complexity of said system. In other words,
> >the configuration for sendmail BETTER be difficult, because the sendmail
> >itself is a very complex system. You would not want to make it EASIER
> >to configure because then you would run into the problem of entry level
> >people trying to configure it and screwing everything up.
>
> But my point would be, why is it so complex ? Can it be made easier ?
>
> Not, it already works, so it must good ; Or that it's as complex as needs
> to be.
When you come up with a system that can do the things that sendmail can
and make it so easy to configure, you will be a wealth man in more ways
than one.
> >Leave systems configuration to the experts.
> >
> >Leave helpdesk tasks to entry-level "administrators."
>
> Interesting. It's quite obvious your not interested in making computer
> systems easier to administer, because it's already solved - that's how I
> make my money, maybe ?. "ease" of administration does not necessarily
> impart skill upon the operator. That's a given. But likewise, complex
> systems don't either, and should be reviewed.
>
> My suggestion was an *inital* attempt at *trying* to address issues with
> home/single user configuration, but combining it with a fundamental system
> change that, if designed/implemented correctly, *could* reduce the amount
> of effort required by developers to achieve this. It would also formalise a
> way to access configuration services, just like we have created standard
> functions, libraries, etc.
>
> You've raised some good points, things that do need to be discussed. But
> the one thing I find most annoying though, is how you've tried to make the
> suggestion what it's not - the subject change is deliberately divisive.
>
> If you don't want things to change, fine. But real progress can only be
> achieved by those that question fundamentals: Horse and buggy, dirt roads,
> punch cards... :)
>
> Anyway, the suggestion is out there, take it or leave it...
I appreciate your goals, but I think they are misfounded. I believe the
more "correct" and useful path would be to create GUI interfaces for the
text based configurations already out there. It would not require any
changes at all to the existing programs, and would give home/small
business users the "easy" configuration you are seeking. I myself
suggested a GUI front end to DNS and DHCP (the "official" ISC versions
of course) that would "look" like Microsofts but really only
create/modify the standard text files that are already in universal
use. This, IMHO, would be much easier to implement than changing the
countless Gigs of source code already out there.
------------------------------
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: Re: subscribe
Date: Thu, 7 Jan 1999 13:38:02 +0100
On 6 Jan 1999, Johan Kullstam wrote:
> JiSook Kim <[EMAIL PROTECTED]> writes:
>
> > subscibe
>
> ok, you are subscribed.
>
> to unsubscribe, send a message to alt.test with the subject
> `unsubscribe <newsgroup>'
NO NO NO you've got it all wrong.
The unsubscription newsgroups changed to alt.flame.me
and alt.2600.warez last month...
Sheez, you must have been living under a rock this
christmas!
Rik -- If a Microsoft product fails, who do you sue?
+-------------------------------------------------------------------+
| Linux memory management tour guide. [EMAIL PROTECTED] |
| Scouting Vries cubscout leader. http://humbolt.geo.uu.nl/~riel |
+-------------------------------------------------------------------+
------------------------------
From: "Harry" <[EMAIL PROTECTED]>
Subject: Re: 2.2.0-pre5 problem with ip_masq.c
Date: Thu, 7 Jan 1999 19:27:54 +0100
Bryan Franklin wrote in message <771nom$c1a$[EMAIL PROTECTED]>...
>I just tried to compile 2.2.0-pre5 with the same options that I compiled
>pre4 with and I get the following errors:
>
>make[3]: Entering directory `/usr/local/src/linux-2.2.0-pre5/net/ipv4'
>gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fo
mit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-j
umps=2 -malign-functions=2 -DCPU=586 -DEXPORT_SYMTAB -c ip_masq.c
>ip_masq.c: In function `__ip_masq_in_get':
>ip_masq.c:544: `IP_MASQ_F_DLOOSE' undeclared (first use this function)
[...]
>
>Upon closer inspection it's obvious that IP_MASQ_F_DLOOSE never gets
defined
>anywhere. Looks like a chunk of a patch got lost somewhere along the way.
>
Putting
#define IP_MASQ_F_DLOOSE 0x0010 /* loose dest binding */
in include/net/ip_masq.h let me compile the kernel.
--
Raphael Wegmann
[EMAIL PROTECTED]
------------------------------
** 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
******************************
