Linux-Development-Sys Digest #763, Volume #7 Wed, 12 Apr 00 18:13:21 EDT
Contents:
Re: To core or not to core - You tell me (Michael Wojcik)
Re: Q: is there a free secure network filesystem for Linux? (Matthew Palmer)
Re: How to debug driver that freezes the system? ("Mr. Oogie Boogie")
Re: How to debug driver that freezes the system? (Kaz Kylheku)
Re: Problem with PLIP, Update: It seems to be a kernel (parport?) problem (Veksler
Michael)
device driver development ("Long")
Re: Linux Daemon problem (Tom Roberts)
Re: To core or not to core - You tell me (Mark McIntyre)
Re: To core or not to core - You tell me (Ron Natalie)
Re: device driver development (Florian Heinz)
schedule_timeout() ("Aurelie Fonteny")
Re: To core or not to core - You tell me (Paul D. Smith)
Re: To core or not to core - You tell me (Mark McIntyre)
Re: To core or not to core - You tell me (Mark McIntyre)
Re: To core or not to core - You tell me (Mark McIntyre)
Re: To core or not to core - You tell me (Mark McIntyre)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 12 Apr 2000 16:48:21 GMT
Reply-To: [EMAIL PROTECTED]
[Followups restricted to comp.lang.c.]
In article <[EMAIL PROTECTED]>, Floyd Davidson <[EMAIL PROTECTED]> writes:
> Dima Volodin <[EMAIL PROTECTED]> wrote:
> >Floyd Davidson wrote:
> >> The macro NULL must be a null pointer constant, which is either
> >> an integral constant expression of value 0 or such an expression
> >> cast to a void*. (In other words, it has an all 0 bit pattern.)
> >There's no requirement that ((void*)0) produced all 0 bit pattern.
> Yes there is. It is a *null pointer constant* with a value of 0,
> and will not be _converted_ to a null pointer unless it is compared or
> assigned to a pointer type.
>
> The *null pointer* is what is not required to be an all 0 bit pattern.
Where does the standard require that the integer constant 0 have an
all-0 bit pattern? And if this is not in fact a requirement, where
is the null pointer constant required to have an all-0 bit pattern?
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Viewers are bugs for famous brands.
-- unknown subtitler, Jackie Chan's _Thunderbolt_
------------------------------
From: [EMAIL PROTECTED] (Matthew Palmer)
Subject: Re: Q: is there a free secure network filesystem for Linux?
Date: 12 Apr 2000 18:51:43 GMT
Reply-To: [EMAIL PROTECTED]
Michael Pronath is of the opinion:
>Is there a network filesystem, that has useful security features (i.e. not
>NFS), and is free and open source available for Linux (i.e. not AFS) ?
>What would you use for a small LAN, Home Office or so? Samba?
For a home/office thing, stick with NFS between Unix hosts and Samba for
the windows boxes. The only way somebody's going to compromise NFS's
security in this situation is through physical access, and if there's
anybody you don't trust with physical access you don't trust you've got
bigger problems than somebody grabbing NFS packets off the wire.
OT, BTW. comp.os.linux.misc would be better, probably.
--
=======================================================================
#include <disclaimer.h>
Matthew Palmer
[EMAIL PROTECTED]
------------------------------
From: "Mr. Oogie Boogie" <[EMAIL PROTECTED]>
Subject: Re: How to debug driver that freezes the system?
Date: Wed, 12 Apr 2000 15:01:59 -0400
Kaz Kylheku wrote:
>
> On Wed, 05 Apr 2000 15:04:44 -0400, Mr. Oogie Boogie <[EMAIL PROTECTED]>
> wrote:
> >Howdy,
> >
> >I'm debugging a PC-card character device driver that I've written and
> >can't
> >figure out what is causing the system to freeze. I'm an experienced C
> >programmer but this is the first Linux programming I've done. The
> >driver is
> >nearly completed. This nasty bug is the last problem I've found. The
> >other
> >problems I was able to find using printk's but I can't get any of the
> >printk
> >output after the system reboots.
>
> Take it easy! You probably did something silly like lock a spinlock and
> forget to unlock it, or in some other way cause an infinite loop.
I finally found the bug that was causing my system to freeze. It was
the atomic system call clear_bit(). I took out all of the atomic
calls, test_and_set_bit(), set_bit(), etc because they also seemed to
freeze my system, but not as often. The clear_bit() call froze my
system about once every 100 times it was used. Luckly, the driver
works fine without the atomic calls. I just did 1,000,000 read/writes
with no problems, hurray!
clear_bit() expands into one assembly instruction. Anybody know why it
would cause the computer to lock up? I'm using a Dell latitude 133Mhz
P2 with Linux v2.2.13
Hope this helps somebody.
--
Ralph A. Preston
The MITRE Corporation
202 Burlington Road, MS E015
Bedford, MA 01730-1420
Work: 781-271-7914 Fax: 781-271-8875 Cell: 617-257-2695
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: How to debug driver that freezes the system?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Apr 2000 19:04:28 GMT
On Wed, 12 Apr 2000 15:01:59 -0400, Mr. Oogie Boogie <[EMAIL PROTECTED]>
wrote:
>Kaz Kylheku wrote:
>> Take it easy! You probably did something silly like lock a spinlock and
>> forget to unlock it, or in some other way cause an infinite loop.
>
>I finally found the bug that was causing my system to freeze. It was
>the atomic system call clear_bit(). I took out all of the atomic
>calls, test_and_set_bit(), set_bit(), etc because they also seemed to
>freeze my system, but not as often. The clear_bit() call froze my
>system about once every 100 times it was used. Luckly, the driver
>works fine without the atomic calls. I just did 1,000,000 read/writes
>with no problems, hurray!
>
>clear_bit() expands into one assembly instruction. Anybody know why it
>would cause the computer to lock up? I'm using a Dell latitude 133Mhz
>P2 with Linux v2.2.13
I find this characterization of the problem hard to believe, because clear_bit
and friends are used in places other than your code.
--
#exclude <windows.h>
------------------------------
From: Veksler Michael <[EMAIL PROTECTED]>
Subject: Re: Problem with PLIP, Update: It seems to be a kernel (parport?) problem
Date: 12 Apr 2000 16:56:42 GMT
Need help to debug PLIP:
I have a similar problem as Martin, but instead of Alpha I have a 500MHz
Intel machine (/proc/cpuinfo says it's Pentium II). Ping gets
100% packet loss both ways. The cable is OK (I have a proof, read on).
It used to work before I switched my old 486 (kernel 2.0.x) with
Pentium II.
Observations (I did compile PLIP with -DNET_DEBUG=10):
1. Packets travel both ways and are received by the other side by the
PLIP driver layer.
(both kernel trace and ifconfig counters prove that).
2. Packets reach the other side uncorrupted (I added printk
traces to plip_send() and plip_receive() on both ends to make sure).
3. Packets from the slow computer are processed by the fast
computer correctly. (slow --> fast link is OK).
The other way does not work for user space apps
(fast --> slow link is broken).
session on the SLOW computer session on the FAST computer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
slow# ping -rvd fast fast# ping -rvd slow
^C 64 bytes from slow (ip of 'slow'):
10 packets transmitted, Echo Request
0 packets received, 100% (the above repeated 10 times)
packet loss
4. ipchains -F was run before the tests to make sure that there is no
packet forwarding/blocking insanity.
It seems that PLIP does not work when one of the computers is extremely
fast (maybe some sort of race).
Can someone tell me what to do next? Is it a bug or is it my fault?
If it IS a bug, debugging tips would be appreciated (I never debugged
in kernel space before).
INFO: fast computer slow computer
system type Pentium II 500MHz+ Pentium MMX 166
Kernel 2.2.14 2.2.5-15
port H/W EPP,ECP EPP,ECP
(= bi-directional) (= bi-directional)
Thanks
Michael
------------------------------
From: "Long" <[EMAIL PROTECTED]>
Subject: device driver development
Date: Wed, 12 Apr 2000 13:19:03 -0700
Please help... anyone,
I am developing a device driver. Everytime after loading using insmod
driver.o and it has an error in the driver. I am forced to reboot the
system to reload the driver. Otherwise it says "driver.o: a module named
driver already exists." Is there anyway that I can undo the loading so that
I can reload the driver without having to reboot the system. I try rmmod
but it says: "rmmod: module driver.o not loaded". Any suggestion is
appreciated.
Long
------------------------------
From: Tom Roberts <[EMAIL PROTECTED]>
Subject: Re: Linux Daemon problem
Date: Wed, 12 Apr 2000 15:27:44 -0500
Manoj Patil wrote:
> 2. However, when I start the server from init routine (rc.d), the server
> does not restart itself when the client asks it to do so.
This is a common problem on other UNIX-s, but I have no direct
knowledge of Linux here.
Check that you catch or ignore all signals, especially SIGHUP and
all terminal-related signals (for debugging, leave SIGQUIT, SIGILL,
SIGBUS, SIGSEGV, ... defaulted). Check that your code NEVER EVER
uses stderr or stdout or stdin. Check that your _libraries_ NEVER
EVER use stderr, stdout, or stdin -- this latter is so onerous that
I ended up freopen-ing them onto /dev/null.
Be aware that init closes fds 0,1,2 and a file open can obtain
those fds. So again it may be best to freopen them onto /dev/null.
The behavior of printf() is undefined when fd 1 is closed, and
on some UNIX-s it hangs forever. I don't know about Linux....
The _REAL_ disaster is when some library routine does a printf()
and your program just happened to get fd 1 when it opened an
important data file (:-().
Tom Roberts [EMAIL PROTECTED]
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 21:37:15 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 12 Apr 2000 09:37:44 -0400, Ron Natalie <[EMAIL PROTECTED]>
wrote:
>
>
>Mark McIntyre wrote:
>
>>
>> Not quite. It must only compare equal to (int)0 when cast to int
>> (either explicitly or implicitly). It may be represented by all-ones
>> or all zeros or half of each.
>
>It's the other way, it's the 0 that is converted to the pointer type
>for the comparison (by virtue of it being a null pointer constant).
exactly. And afterwards you have *absolutely no idea* how its stored.
>It is not required that casting a null pointer to int return any
>specific value (at least in C++, where it says the mapping is implementation
>defined).
and in C. Hence the NULL macro need not be all zero bits since
(void*)0 may be stored in any old way.
>< If you were to compare it to char* or
>> double or something else
>
>Again in C++, casting a null pointer of one type to another pointer type is
>supposed to result in the null pointer of that type.
Probably, but does the standard say that a null char pointer is
all-zero bits?
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Ron Natalie <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 16:53:50 -0400
Mark McIntyre wrote:
>
> Probably, but does the standard say that a null char pointer is
> all-zero bits?
No, I never said it did. I was just correcting your error when you
said
Not quite. It must only compare equal to (int)0 when cast to int
(either explicitly or implicitly).
This statement is incorrect. Even the null pointer is not required
to evaluate to zero when cast back to int. Casting a pointer to
int is an implementation defined function. It's quite possible on
your hypothetical machine where the null pointer isn zero bits, that
the cast back to int value is not zero as well.
You then make this inaccurate statement:
If you were to compare it to char* or
double or something else, then the conversion would not be guaranteed
if "it" in the sentence is to mean a pointer set to the null pointer.
This is wrong, once the null pointer value is set in a pointer, the conversion
to other pointers is well defined and yields the null pointer valuve for the
type of the pointer converted to.
------------------------------
From: Florian Heinz <[EMAIL PROTECTED]>
Subject: Re: device driver development
Date: Wed, 12 Apr 2000 23:04:41 +0200
Long wrote:
>
> Please help... anyone,
>
> I am developing a device driver. Everytime after loading using insmod
> driver.o and it has an error in the driver. I am forced to reboot the
> system to reload the driver. Otherwise it says "driver.o: a module named
> driver already exists." Is there anyway that I can undo the loading so that
> I can reload the driver without having to reboot the system. I try rmmod
> but it says: "rmmod: module driver.o not loaded". Any suggestion is
> appreciated.
perhaps you should use the name which lsmod shows you as argument for
rmmod...
e.G. not "rmmod driver.o" but "rmmod driver"...
------------------------------
From: "Aurelie Fonteny" <[EMAIL PROTECTED]>
Subject: schedule_timeout()
Date: Wed, 12 Apr 2000 16:32:11 -0500
Hi,
I want to delay a task for 1 s. This task is inside of a transmission
procedure for a network device driver. So here is how it looks like :
start_bh_atomic();
<CODE>
current->state = TASK_UNINTERRUPTIBLE;
schedule_timeout(HZ);
<CODE>
end_bh_atomic();
When I run the driver and it goes to this part of the code, nothing is
responding anymore : mouse is not working, I can't type anything..., and I
just can do a reset! And when I delete the two line with current->state ans
schedule_timeout(), it's working fine.
Does anyone know why?
Thanks
Aurelie
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 12 Apr 2000 17:59:12 -0400
Reply-To: [EMAIL PROTECTED]
%% Mark McIntyre <[EMAIL PROTECTED]> writes:
mm> "An integer constant expression with the value 0, or
mm> such an expression cast to type void *, is called a null
mm> pointer constant."
mm> This says that either its (int)0
Since we're picking nits, (int)0 is not an integer constant. You mean
just 0 (or 0L or 0U or 0UL).
--
===============================================================================
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: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 22:59:19 +0100
Reply-To: [EMAIL PROTECTED]
On 11 Apr 2000 16:54:39 -0800, Floyd Davidson <[EMAIL PROTECTED]>
wrote:
>Mark McIntyre <[EMAIL PROTECTED]> wrote:
>>Floyd Davidson <[EMAIL PROTECTED]> wrote:
>>>Dima Volodin <[EMAIL PROTECTED]> wrote:
>>>>Floyd Davidson wrote:
>>>>
>>>>> The macro NULL must be a null pointer constant, which is either
>>>>> an integral constant expression of value 0 or such an expression
>>>>> cast to a void*. (In other words, it has an all 0 bit pattern.)
>>>>
>>>>There's no requirement that ((void*)0) produced all 0 bit pattern.
>>>
>>>Yes there is. It is a *null pointer constant* with a value of 0,
>>>and will not be _converted_ to a null pointer unless it is compared or
>>>assigned to a pointer type.
>>
>>No there isn't. Reread 6.3.2.3 again
>>
>> "An integer constant expression with the value 0, or
>> such an expression cast to type void *, is called a null
>> pointer constant."
>>
>>This says that either its (int)0 or else (void*)(int)0. it says
>>nothing at all about whether the bit pattern is all-zeros or all ones.
>>
>>And by the way, if the hardware chooses to store (void*)0 as all-ones
>>then thats up to it. the C standard makes no assertions at all about
>>that!
>
>Where does that allow the value of an "null pointer constant" to
>be anything except a value of 0? Are you not confusing a "null
>pointer constant" with a "null pointer"? The entire context of
>6.2.2.3 (note, not 6.3.2.3) is:
umm, there isn't a 6.2.2.3 in n2794... or in n869. One of us is
looking at the wrong document. Are you by any chance reading the C++
standard?
> "An integral constant expression with the value
> 0, or such an expression cast to type void *,
> is called a _null_pointer_constant_. If a null
You make my point. Reread this carefully. All it says is that NULL is
(int)0 or (void*)(int)0. It makes no assertions about the bitpattern.
> pointer constant is assigned to or compared for
> equality to a ponter, the constant is converted
> to a pointer of that type. Such a pointer,
> called a _null_pointer_, is guaranteed to
> compare unequal to a pointer to any object or
> function.
>
> Two null pointers, converted through possibly
> different sequences of casts to pointer types,
> shall compare equal."
>
>It is not the "null pointer constant" which can have an
>implementation defined bit pattern,
> it is the "null pointer".
Where does it say that (void*)(int)0 is all zeros bits? It does not.
>They are distinctly to different concepts, and a "null pointer
>constant" is only converted to a "null pointer" under the two
>explicit circumstances.
>Essentially,
>
> if (NULL) {...}
>
>does not cause the null pointer constant to be converted to a
>null pointer, while,
>
> char *p = NULL;
> if (p) {...}
>
>does result in a null pointer. That is the way I read it, and
>it appears to reduce the number of places where a conversion to
>a null pointer takes place. It also allows each type to more
>easily have a different bit representation for a null pointer of
>that type.
>
> Floyd
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 22:59:21 +0100
Reply-To: [EMAIL PROTECTED]
On Tue, 11 Apr 2000 16:50:07 -0700, Erik Max Francis <[EMAIL PROTECTED]>
wrote:
>Mark McIntyre wrote:
>
>> In fact the standard says nothing at all about the bitpattern of NULL
>> so long as it is either (int)0 or (void*)(int)0.
>
>NULL is a macro. The confusion happening here is that people are mixing
>up the concepts of NULL (the macro), the null pointer constant
NULL is defined as a null pointer constant.
> (the
>expression in C or C++ that you write to get a null pointer -- 0 or
>(void *) 0), and the null pointer itself (which is the
>platform-dependent pattern pattern of bits in a pointer context).
>Everyone is saying the same thing, but some are using less clear
>language and are misinterpreting what others are saying.
Agreed. I'm talking about NULL, the macro which 6.3.2.3 and 7.17 in
the ANSI/ISO C standard defines as the null pointer constant.
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 22:59:22 +0100
Reply-To: [EMAIL PROTECTED]
On Tue, 11 Apr 2000 16:46:40 -0700, Erik Max Francis <[EMAIL PROTECTED]>
wrote:
>Mark McIntyre wrote:
>
>> This says that either its (int)0 or else (void*)(int)0. it says
>> nothing at all about whether the bit pattern is all-zeros or all ones.
>>
>> And by the way, if the hardware chooses to store (void*)0 as all-ones
>> then thats up to it. the C standard makes no assertions at all about
>> that!
>
>He knows that. Don't mix up the null pointer constant 0 or (void *) 0
>with the null pointer itself, which may be represented internally as
>something other than than all-bits-zero.
I'm not. Really I'm not. I'm reading the standard as I write this just
to be sure!
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Wed, 12 Apr 2000 22:59:23 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 12 Apr 2000 09:38:49 -0400, Ron Natalie <[EMAIL PROTECTED]>
wrote:
>
>
>Mark McIntyre wrote:
>
>> This says that either its (int)0 or else (void*)(int)0. it says
>> nothing at all about whether the bit pattern is all-zeros or all ones.
>
>That's the C rules, in C++ the void* cast is not part of the null pointer
>constant. The null pointer constant is always something that evaluates
>to zero.
Which indicates (a) the virtue of not crossposting and (b) the virtue
of mentioning which standard you are working with...
I'm living in ANSI C land here. In ANSI C the NULL macro is defined as
a null pointer constant (see section 7.17 of n869) and the null
pointer constant is defined as (int)0 or (void*)(int)0 (see section
6.3.2.3 of same doc).
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
** 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
******************************
