Linux-Development-Sys Digest #751, Volume #7 Fri, 7 Apr 00 21:13:15 EDT
Contents:
Re: Problem with PLIP (via laplink cable) (Ed Carp)
Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
Re: block device development ("Fabrizio")
Re: Am I the only person around with a 40 gig HD? (Dave Nejdl)
Versioning, Versioning,... What's the deal? (ravi Venkat)
Re: How compatible is Linux with .. Linux (Tramm Hudson)
Re: Problem with PLIP (via laplink cable) (Anders Larsen)
Re: Am I the only person around with a 40 gig HD? ("Bobby Hitt")
Re: Multiple kernel versions on same system (William Burrow)
Re: Problem with PLIP (via laplink cable) (Ed Carp)
Re: Am I the only person around with a 40 gig HD? (Chris)
Re: mmap PROT_NONE proposal (Nix)
Re: system calls table: where is it? (Nix)
Re: Linking error with thread program (Nix)
online ref for shared libraries ([EMAIL PROTECTED])
Re: Overrunning the stack (Juergen Heinzl)
----------------------------------------------------------------------------
From: Ed Carp <[EMAIL PROTECTED]>
Subject: Re: Problem with PLIP (via laplink cable)
Date: Fri, 07 Apr 2000 13:03:23 -0500
Martin Kahlert wrote:
>
> Hi,
> i just wanted to connect my ooooold laptop (i486) to my
> Linux AXP machine using plip (laplink cable), yesterday.
This is probably where your problem lies. PLIP needs a straight-through
cable, and the LapLink cable has various things done to it that support
LapLink, but will make it unsuitable. Try getting a straight-through
male/male cable.
Alternateively, you could get a PCMCIA network card for your laptop if
it supports PCMCIA.
BTW, this probably doesn't belong here - it's more of a networking
problem ;)
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 7 Apr 2000 18:47:08 GMT
In comp.os.linux.development.system The Wogster <[EMAIL PROTECTED]> wrote:
: Peter T. Breuer wrote in message <8ccqgp$eg2$[EMAIL PROTECTED]>...
:>In comp.os.linux.development.system The Wogster <[EMAIL PROTECTED]>
: wrote:
:>
:>: VMS, HPUX, AIX, Irix, MVS, VSE or other environment. Heck, three years
:>: ago, I could have asked the same question!
:>
:>OK, what IS the difference between VMS and MVS, then! Apart from the
:>first letter (of their manufacturer).
: Gee now maybe a number of people can berate you on not knowing the
: difference between a mini and big iron.....
Are you personally too determined to pick a fight than to understand a
point when it is made? I'm asking the other person to speak up if he
knows! Not that I know too much here, or care. I know just about
the following that you quote and a bit more.
So what is the difference between a mini and big iron then? Speak up
... ;)
: VMS: OS used by Digital Equipment Corporation on it's VAX series of
: computers, these are classed as mini computers, very similar to Unix in many
: ways, really different in other ways. Best feature, smooth scrolling on
: text based terminals no less. Could be crashed by 45 College students
: starting a COBOL compile at the same time.
Not in the classical sense of crashing.
: MVS: OS used by International Business Machines on their biggest iron, the
: only similarity to Unix is the fact that it runs multiple users and multiple
: tasks at the same time. Best feature, you can actually run MVS as an
: application under MVS (VM the other IBM Big Iron OS also has this feature).
: MVS (and VM) are almost totally crash proof I used to work with these
: systems, and running for many months is common.
I have run and worked under both. Both too long ago to even want to
remember (memories of nights spent feeding tapes into the IBM 370
between writing chess-playing programs in fortran scanned from incoming
card decks). I never saw a crash, but planned downtime was common.
Peter
------------------------------
From: "Fabrizio" <[EMAIL PROTECTED]>
Subject: Re: block device development
Date: Fri, 07 Apr 2000 19:45:00 GMT
"Gennadiy M. Kurtsman" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:8chp7c$18d$[EMAIL PROTECTED]...
> I had such problem not so long ago. Asking help I got answer that
..._xxxxx
> is versioning information. You can see it using *ksyms -a* command. I
don't
> know how to include or exclude it to/from your module, but I guess that if
> you recompile Linux kernel you'll get simultaneous versioning state for
the
> kernel and your module.
> Best regards,
> Gennadiy.
Hi Gennadiy,
thanks for your reply. In the mean time I arrived at the same point. Looking
at the archive I found other few messages, but almost saying the same thing,
without any practical solution. I also investigated a bit more. Compilng the
module with the -E option I have been able to capture the output of the C
preprocessor. It looks like that "kernel.h" define printk in "naked" mode
(i.e. no _xxxx have been added), meanwhile the reference to printk in the
body of my module are "versioned" by a mechanism that I cannot understand...
I'm going to compile a new kernel without the the "version symbol support",
hoping that will help...
Poca!
>
> Fabrizio wrote in message ...
> >Now a question: I'm trying the chardev.c module from the book. No problem
> >with the compilation, but when I try to insmod the module I've some
> >unresolved symbols related to printk_xxxxxx and sprintf_xxxxxx, where
xxxxx
> >are sume hex numbers.
> >
> >Hints ? Suggestions ?
> >
> >Ciao!
------------------------------
From: Dave Nejdl <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Am I the only person around with a 40 gig HD?
Date: Fri, 07 Apr 2000 19:58:31 GMT
ya, I think it's called vfat.
Dave
------------------------------
From: ravi Venkat <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux
Subject: Versioning, Versioning,... What's the deal?
Date: Fri, 07 Apr 2000 12:37:34 -0700
Hello Group,
I want to know about versioning in detail. I read Linux Device Drivers
by Rubini and
I do understand the basics but I am interested in the details. I know
that modsetver.h,
module.h is the file to go thru to understand, but if there is some
document out there to make it easy.
My question is if I have a package in binary for which I downloaded from
a web site, how can i make it
run on any kernel version (or any version of the kernel build)
I appreciate it very much.
--Ravi
------------------------------
From: [EMAIL PROTECTED] (Tramm Hudson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 7 Apr 2000 20:32:27 GMT
[posted and cc'd to cited author]
The Wogster <[EMAIL PROTECTED]> wrote (with some snippage):
>VMS: Best feature, smooth scrolling on text based terminals no less.
To be pedantic, the VT220 and higher terminals have a configurable
option for smooth or jump scrolling. They will do this independant
of the operating system that is driving them.
I find that the smooth scroll is very annoying. Much, much slower
overall scrolling. It makes a 19.2 kbaud connection feel like a
300 baud link.
I would suggest several other features as the best of VMS.
These topics are probably better discussed in alt.folklore.computers...
Follow-ups set.
Tramm
--
o [EMAIL PROTECTED] [EMAIL PROTECTED] O___|
/|\ http://www.swcp.com/~hudson/ H 505.323.38.81 /\ \_
<< KC5RNF @ N5YYF.NM.AMPR.ORG W 505.284.24.32 \ \/\_\
0 U \_ |
------------------------------
From: Anders Larsen <nobody@localhost>
Subject: Re: Problem with PLIP (via laplink cable)
Date: Fri, 07 Apr 2000 22:53:54 +0200
Ed Carp wrote:
>
> Martin Kahlert wrote:
> >
> > Hi,
> > i just wanted to connect my ooooold laptop (i486) to my
> > Linux AXP machine using plip (laplink cable), yesterday.
>
> This is probably where your problem lies. PLIP needs a straight-through
> cable, and the LapLink cable has various things done to it that support
> LapLink, but will make it unsuitable. Try getting a straight-through
> male/male cable.
Ed, are you 100% sure about that?
A straight-through cable connects outputs to outputs and inputs to inputs,
which is a Bad Thing (tm) to the electronics.
The source plip.c starts with these two lines:
/* PLIP: A parallel port "network" driver for Linux. */
/* This driver is for parallel port with 5-bit cable (LapLink (R) cable). */
and later explicitly states:
The cable used is a de facto standard parallel null cable -- sold as
a "LapLink" cable by various places. You'll need a 12-conductor cable to
make one yourself. The wiring is:
SLCTIN 17 - 17
GROUND 25 - 25
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
Do not connect the other pins. They are
D5,D6,D7 are 7,8,9
STROBE is 1, FEED is 14, INIT is 16
extra grounds are 18,19,20,21,22,23,24
There was some mentioning of the driver being incompatible with Linux 1.0.x
but nothing about problems with 2.0.x <=> 2.2.x
> Alternateively, you could get a PCMCIA network card for your laptop if
> it supports PCMCIA.
>
> BTW, this probably doesn't belong here - it's more of a networking
> problem ;)
Nod.
Anders Larsen
e-mail: my initials at alarsen dot net
--
#exclude <windows.h>
------------------------------
From: "Bobby Hitt" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Am I the only person around with a 40 gig HD?
Date: Fri, 7 Apr 2000 16:55:26 -0400
There's absolutely no reason why you can't use FAT32 and access from both
Linux and Windows 95/98/2000. In the Linux kernel configuration, you
specify:
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
and recompile. Then in your fstab:
/dev/hdxx /dos vfat defaults 1 1
where "xx" is your fat32 partition.
I'm using 2.2.14 here with multiple fat32 partitions.
Bobby Hitt
"Steve Martin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Victor A. Grinberg" wrote:
>
> > As you can tell I'm proud of my new 40 GB HD :-). Here's my problem: I
> > put a 24GB FAT32 partition at the end of the drive, for data, so I could
> > access it from both win98 and linux. Win 98 can get to it fine, which
> > means the partition is properly formatted :-). Linux can't mount it,
> > however. Is this a bug in linux FAT32 support??
>
> Victor:
>
> I'm running 2.2.14 here, so I took a dash over to /usr/src/linux and
> checked... I don't think this kernel even supports FAT32 (at least
> there's no option for it in "make xconfig"). It supports FAT,
> but no mention of FAT32.
>
> I'm sure there's someone on this ng that knows more about it than
> I do, and hopefully they'll speak up if I'm wrong, but you may be
> SOL trying to access FAT32.
------------------------------
From: [EMAIL PROTECTED] (William Burrow)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Multiple kernel versions on same system
Date: 7 Apr 2000 21:39:32 GMT
Reply-To: [EMAIL PROTECTED]
On 7 Apr 2000 00:19:33 -0500,
Paul Kimoto <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Dave Nejdl wrote:
>> I am developing software that interacts with the linux kernel, and I
>> want to test the software on different
>> kernel versions(2.0, 2.2, 2.4-soon I hope). I know I can untar the
...
>> /usr/src/linux, but I'm running the 2.0 kernel with that
>> source tree in /usr/src/linux-2.0, is there an easy way to make gcc use
>> the kernel sources in the 2.0 directory.
>
>You could also move /usr/src/linux to /usr/src/linux-2.2 and make
>/usr/src/linux a symbolic link to the right place (e.g., using a
>clever script at bootup time).
Classically, the kernel header files of interest to the system were
found via a link in /usr/include to /usr/src/linux/include. Package
based systems seem to break this, but this is easy to correct. As
suggested, make /usr/src/linux a link to the appropriate kernel source
directory at boot time.
I have not seen it to date, but I keep multiple kernels and system maps
in /boot, and have a boot script set the correct system map file for the
currently running kernel. This is all fairly easy to implement:
ln -sf /boot/System.map-`uname --release` /boot/System.map
ln -sf /usr/src/linux-`uname --release` /usr/src/linux
--
William Burrow -- New Brunswick, Canada o
Copyright 2000 William Burrow ~ /\
~ ()>()
------------------------------
From: Ed Carp <[EMAIL PROTECTED]>
Subject: Re: Problem with PLIP (via laplink cable)
Date: Fri, 07 Apr 2000 16:47:04 -0500
Anders Larsen wrote:
> There was some mentioning of the driver being incompatible with Linux 1.0.x
> but nothing about problems with 2.0.x <=> 2.2.x
I sit corrected :) I haven't used PLIP since 0.97, and I had assumed
Russ hadn't changed the driver since.
------------------------------
From: [EMAIL PROTECTED] (Chris)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Am I the only person around with a 40 gig HD?
Date: Fri, 07 Apr 2000 22:51:09 GMT
On Fri, 07 Apr 2000 03:11:08 -0400, "Victor A. Grinberg"
<[EMAIL PROTECTED]> wrote in comp.os.linux.hardware:
> Win 98 can get to it fine, which
>means the partition is properly formatted :-). Linux can't mount it,
>however.
Why don't you post a copy of your partition table, /etc/fstab file and the
results of your mount command?
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: mmap PROT_NONE proposal
Date: 07 Apr 2000 16:58:17 +0100
[EMAIL PROTECTED] writes:
> I think it should allocate memory with the allocator, but not in the
> swap file at all. So I can, say, mmap 256 MB with PROT_NONE, then unmap
> and re-mmap to /dev/zero (or a file) as much as I want, without fearing
> that a library using mmap(NULL, ...) has eaten up my space.
This is, after all, what mmap() is for in the first place. Writable
mmap()s do not go via the swap file --- not in Linux, at least. What
would be the point? They go via the file being mmap()ed.
Also, with mmap(), on many platforms, the limiting factor is address
space. With your semantics, an mmap() with PROT_NONE would still eat up
*that*.
> This is useful if you want to use a kind of separate areas managed
> like the standard brk area. Win32 (argh! ;-) ) has this function through
> its VirtualAlloc and VirtualFree functions.
So does Unix, via, well, mmap(). Look at glibc-2.1.3/malloc/malloc.c;
the memory arena for malloc() is partially managed via brk()/sbrk() and
partially via anonymous mmap()ings of /dev/zero.
--
`ndbm on Linux is an emulation, not the original. It comes in several
flavours; `slightly broken', `moderately broken', and `totally and
utterly broken'.' --- Nick Kew
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: system calls table: where is it?
Date: 07 Apr 2000 17:18:30 +0100
[EMAIL PROTECTED] writes:
> Please, can somebody point me to this piece of information (source and
> docs)?
It depends on the architecture. In 2.2.14 (the latest kernel I have to
hand):
linux-2.2.14/arch/i386/kernel/entry.S
linux-2.2.14/arch/alpha/kernel/entry.S
linux-2.2.14/arch/m68k/kernel/entry.S
linux-2.2.14/arch/arm/kernel/calls.S
linux-2.2.14/arch/mips/kernel/syscalls.h !
linux-2.2.14/arch/ppc/kernel/misc.S
linux-2.2.14/arch/s390/kernel/entry.S
linux-2.2.14/arch/sparc/kernel/systbls.S !
linux-2.2.14/arch/sparc64/kernel/systbls.S
so it tends to be in linux/arch/{arch}/kernel/entry.S, but this is not
always true.
I've always thought this is a little bit of a kludge; ideally a
`universal syscall table' with arch-specific additions would be
possible, but unfortunately this is torpedoed by the Sparc, which has a
SunOS compatibility syscall table with completely different numbers, and
by the MIPS, which has its, er, own unique numbers, apparently to leave
space for the SVR4, IRIX, and BSD4.3 syscalls (why? to have programs
mistakenly using those fall over when run rather than doing random wrong
things?)
--
`ndbm on Linux is an emulation, not the original. It comes in several
flavours; `slightly broken', `moderately broken', and `totally and
utterly broken'.' --- Nick Kew
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Linking error with thread program
Date: 07 Apr 2000 17:19:48 +0100
<[EMAIL PROTECTED]> writes:
> On Wednesday, April 5, 2000 5:34 AM Chuck Winters
> <[EMAIL PROTECTED]> wrote:
>
> If you are using the pthread lib, just pout a -lpthread on gcc's command line
ITYM `-pthread', which on many arches is the same as `-D_REENTRANT
-lpthread', but not on all.
--
`ndbm on Linux is an emulation, not the original. It comes in several
flavours; `slightly broken', `moderately broken', and `totally and
utterly broken'.' --- Nick Kew
------------------------------
From: [EMAIL PROTECTED]
Subject: online ref for shared libraries
Date: Sat, 08 Apr 2000 00:39:05 GMT
I'm having a little trouble getting some c code I've written to work as
shared libraries.
Does anyone know any good online references that can teach me how to
create shared libraries for linux?
Does anyone know of any linux development books that talk cover creating
shared libraries indepthly?
Thanks,
Tait
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Overrunning the stack
Date: Sat, 08 Apr 2000 00:52:57 GMT
In article <8cj7uc$mm8$[EMAIL PROTECTED]>, Jon Becker wrote:
>In article <[EMAIL PROTECTED]>,
>Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>>On Thu, 06 Apr 2000 21:13:24 GMT, Juergen Heinzl
>><[EMAIL PROTECTED]> wrote:
>>>In article <8cgf6s$d70$[EMAIL PROTECTED]>, Jon Becker wrote:
>>>As there is no answer yet I hope this rings a bell, IIRC there was
>>>a discussion regarding that issue quite some time ago on ...
>>>http://kt.linuxcare.com/
>>>... and, again IIRC, the proposed solution was to use a read-only
>>>memory page to guard against that problem.
>>
>>Note that this is not a concern if you are using LinuxThreads (at least for
>>threads other than the main one). LinuxThreads does leave an unmapped area at
>>the top limit of each stack.
>>
>>If you are managing your own stacks, you can just mmap the region you need and
>>then use mprotect to poke a hole in it somewhere.
>
>
>Let me be a little clearer. Suppose I'm running a regular program as
>a regular process. There's nothing special here (almost): no threads,
>no special stack management, no nothing. The only issue is that the
>address space is kind of full. Maybe I link against a whole bunch of
>shared libraries, maybe I need to mmap a whole bunch of files,
>whatever. And I have a lot of large stack variables and let's say
>some deep recursion, so the stack gets quite big.
[...]
Yes, I think that was quite clear and the pthreads stuff is just
a special case.
>If the program isn't doing anything special, if something happens to
>get mapped right below the stack, then the stack might crash right
>into that memory and corrupt it. And that's just the way it goes?
>That doesn't seem right to me.
[...]
AFAIK .. yes.
>In essence, my process is running out of some resource (address
>space), and it wouldn't be too hard for the kernel to notice this and
>fault my process right away. But instead, it sounds like my data will
>get corrupted and I just have to wait for something to die later as a
>result.
>
>Is that really the case?
[...]
If I got that right, then see my previous reply. I remember a short
discussion but with so much stuff going on ... I did not archive the
related article. Same applies to "what is the current state of
affairs" as I am still using kernel 2.2.14 and have not followed
latest developments. I have tried to find the URL, but the keyword
"stack" results in an endless string of articles, so I'd really
recommend to ask on the linux.dev.kernel list for a final and
authorative answer.
Still given the currently used memory layout I guess the only
solution is to put a non-writable page between the process' stack
and mapping area.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
** 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
******************************
