Linux-Development-Sys Digest #754, Volume #7 Mon, 10 Apr 00 02:13:13 EDT
Contents:
Re: Help me complain to atitrust agency against canon's windows supportiveness!
([EMAIL PROTECTED])
Re: To core or not to core - You tell me (Michael Wojcik)
Re: drivers ([EMAIL PROTECTED])
Re: conflicting header files (Jerry Peters)
Re: Overrunning the stack (David Wragg)
Re: To core or not to core - You tell me (Ron Natalie)
Re: To core or not to core - You tell me (Ron Natalie)
Re: To core or not to core - You tell me (Ron Natalie)
Re: Creating a new System Call (Dave Nejdl)
about share memory and semaphore ("Eddy")
Re: Partition Access ([EMAIL PROTECTED])
Re: type inconsistency in open(2) ([EMAIL PROTECTED])
Re: Problem with PLIP, Update: It seems to be a kernel (parport?) problem (Martin
Kahlert)
delay start up for somve services ("Eddy")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help me complain to atitrust agency against canon's windows
supportiveness!
Date: Sun, 09 Apr 2000 20:15:35 GMT
On Sun, 9 Apr 2000 16:16:42 +0200 Norwegian Woods <[EMAIL PROTECTED]> wrote:
| Send the following to [EMAIL PROTECTED] :
|
| I hereby presents a complaint about Canon U.S.A. Inc.(from now on reffered
| to as Canon). I think that Canon is breaking The Clayton Act. They provide
| drivers for only operating systems made by Microsoft Corporation (Windows
| 2000, Windows 98, and Windows 95). Goto
| http://128.11.41.160/goto.shtml?/techsupport/downloads/index.html and look
| at the Canon BJC 4400 and similar products. You will clearly see that a lot
| of there product can only be used with operating system made by Microsoft
| Corporation. Thereby preventing the consumer from choosing freely among
| operating systems (Linux, PowerMac, and BeOS). That is against The Clayton
| Act.
|
| Greetings
| from
| <your name>
|
| PLEASE for the sake of open source & free mind.
Please quote the Clayton Act so people know and understand what it means.
--
| Phil Howard - KA9WGN | My current boycotts: Amazon.Com, DVDs, Mattel, Sony
| [EMAIL PROTECTED] +----------------------------------------------------
| Dallas - Texas - USA | My current websites: linuxhomepage.com, ham.org
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: 9 Apr 2000 19:31:09 GMT
Reply-To: [EMAIL PROTECTED]
[comp.lang.c++ removed from newsgroups, and followups set to
comp.lang.c and alt.folklore.computers, where someone probably knows
of other examples.]
In article <[EMAIL PROTECTED]>, Joe Pfeiffer <[EMAIL PROTECTED]>
writes:
> Having said that, I don't know of any actual implementation using
> anything other than all zeroes for NULL [in C].
There are some implementations where the representation of the null
pointer is at least not a valid integer representation.
The old AS/400 EPM C, for example, used a 128-bit (16 byte) pointer
representation. It did not support any 128-bit integer representa-
tion, so even if the representation of the null pointer was binary
zeros (I don't believe it was), it wasn't equivalent to any 0
integer value, and the compiler did indeed have to special-case the
equivalence of 0 and a null pointer (so ptr == 0 worked correctly).
As I recall, all valid EPM pointers - including the null pointer -
had the MSB set, so NULL would be represented in memory as something
like 0x80000000000000000000000000000000. That MSB was automatically
cleared by any modification of an EPM pointer that wasn't done
through the proper AS/400 microinstructions, so for example declaring
something like
union
{
char *my_ptr;
char screw_with_my_ptr[16];
}
and then fiddling with the bytes of screw_with_my_ptr would
immediately invalidate my_ptr, and the next access to my_ptr would
trap.
In printf's %p conversion you'd get this nice little descriptive
string - something like "EPM:SPACE:...:OFFSET:...", with hex
numbers where the elipses are.
I haven't had to look at the intricacies of pointer implementation
in subsequent AS/400 C dialects (System C and then ILE C), so I
don't know if this is still true.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Most people believe that anything that is true is true for a reason.
These theorems show that some things are true for no reason at all,
i.e., accidentally, or at random. -- G J Chaitin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: drivers
Date: Sun, 09 Apr 2000 20:27:31 GMT
On Sun, 09 Apr 2000 18:59:28 GMT Ivan Van den Bossche
<[EMAIL PROTECTED]> wrote:
| Is there somebody who can tell me where to find documentation about how
| to write drivers especially videodrivers for Linux???
http://www.oreilly.com/catalog/linuxdrive/
Help support those who help support Linux.
--
| Phil Howard - KA9WGN | My current boycotts: Amazon.Com, DVDs, Mattel, Sony
| [EMAIL PROTECTED] +----------------------------------------------------
| Dallas - Texas - USA | My current websites: linuxhomepage.com, ham.org
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: conflicting header files
Date: Sun, 09 Apr 2000 20:41:32 GMT
[EMAIL PROTECTED] wrote:
> On Sun, 09 Apr 2000 10:48:04 +0200 Markus Kossmann <[EMAIL PROTECTED]> wrote:
> | [EMAIL PROTECTED] wrote:
> |>
> |> When I get compile errors like those shown below, I wonder what is going
> |> on with this. Can anyone tell me why it is that some things have to be
> |> defined in more than one place, and cannot be included from a singular
> |> place that uses #ifndef to block redundancies?
> | [...]
> |>
> |> In file included from /usr/include/stdio.h:40,
> |> from ttyresize.c:41:
> |> /usr/include/bits/types.h:95: warning: `__NFDBITS' redefined
> |> /usr/include/linux/posix_types.h:22: warning: this is the location of the
>previous >definition
> |
> | Well,it seems you are tring to compile sources designed for libc-5 on a
> | libc-6 system .
> |
> | On a libc-5 system, the kernel headers were integral part of the libc
> | includes. But on a libc-6 system you _must_not_ use the kernel header
> | files for user level programs.
> | To compile that program , you have to replace all #include <linux/*.h >
> | and <asm/*.h> by their libc-6 counterparts.
> It compiles OK (but does not link due to missing functions "outw", "outb",
> and "inb") in Slackware 7.0 (libc-6 based, right?) but the compile failure
> where I see the redundancy in the headers is in Redhat 6.0 (also libc-6
> based, right?).
IIRC these are inline functions. You need to use -O or -O2 to get gcc to
inline them.
> So what are the libc-6 counterparts? How do I name translate a header for
> one into a header for the other other? Is there a name to name mapping or
> is there a simple subdir where all the stuff is in? I know it's NOT "sys"
> because that's what the program _IS_ including.
> The exact program I am compiling (because I can't use the binary of it due
> to an incomplete PCI device vendor table which I need to add to) in case
> you want to try it yourself is:
> ftp://metalab.unc.edu/pub/Linux/utils/console/SVGATextMode-1.9-src.tar.gz
> --
> | Phil Howard - KA9WGN | My current boycotts: Amazon.Com, DVDs, Mattel, Sony
> | [EMAIL PROTECTED] +----------------------------------------------------
> | Dallas - Texas - USA | My current websites: linuxhomepage.com, ham.org
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Overrunning the stack
Date: 08 Apr 2000 13:31:22 +0000
[EMAIL PROTECTED] (Jon Becker) writes:
> It would also be
> possible to just ensure whenever the stack grows and whenever a
> mapping is created that there's a one-page hole below the stack.
It wouldn't be that difficult to modify the kernel so that when
growing the stack mapping of the process, it checks that there is a
hole of N pages between the bottom of the stack mapping and the top of
the mapping below, and kills the process if this hole cannot be
maintained.
But how big do you make that hole? A one page hole isn't generally
sufficient. Consider this perfectly reasonable C code:
struct buffer {
int used;
char data[BUFFER_LEN];
};
extern void fill_buffer(struct buffer *);
void foo(void)
{
struct buffer buf;
buf.used = 0;
fill_buffer(&buf);
/* Now do something with buf.data */
}
Typically, the machine code for foo will lower the stack pointer by
sizeof(struct buffer) bytes, then do the store corresponding to
"buf.used = 0;". By making BUFFER_LEN big enough, that store will
reach over "reach over" the hole, possibly into heap data. And
depending on what the rest of the program does, it's possible that no
access to the hole will ever be made, so the problem will never be
made obvious.
For the same reason, guard pages do not offer full protection. But the
process gets to decide whether that protection is worthwhile, the
kernel just provides the mechanism.
This issue is a general feature of paged MMUs, rather than something
specific to Linux. If it has become a problem, that is because the
limits of a 32-bit address space has been reached.
There is actually a way to do what you want on x86: Set up a custom
stack segment. It should have its base at 0 (so that code expecting a
flat address space continues to work), and be set to expand-down (so
that the segment limit gives the minimum allowed offset rather than
the maximum). The segment limit should be adjusted when the stack hits
it causing a general protection exception (I think you can pull this
off from user-space, but I'm not sure).
This approach is still not completely reliable for normal C compilers,
since they may transfer an address based on ESP/EBP into another
register which is not constrained by the stack segment. But it's much
closer to what you want.
However, I think the practical options are:
- Estimate how big your heap and stack could get (or the ratio of how
big they could get), and set up the max stack size/guard page(s)
appropriately.
Or
- Move to a 64-bit platform.
David Wragg
------------------------------
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, 05 Apr 2000 10:07:09 -0400
Joe Pfeiffer wrote:
>
> David Williams <[EMAIL PROTECTED]> writes:
> >
> > a) 0 == NULL (an integral constant expression with value 0...
> > converted by comparsion...this produces a null pointer..)
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > ??? are they the same or not?? NB A conversion could be taking
> > place implying that they are not.
>
> This is a subtle point, and you've picked up on it perfectly. It is
> possible, in principle, for the conversion to take place so that
> (void *) 0 is not a word full of all zeroes, and NULL need not be
> represented as all zeroes.
NULL is necessarily an integer zero constant.
When converted to an actual pointer it may as you say be something else.
I have seen exactly one machine where you couldn't use zero because it
would cause the machine to trap (even before you try to dereference it)
because that was it's idea of what to do with an illegal pointer value.
The null pointer value actually ended up being a piece of real memory
not used for anything else.
------------------------------
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, 05 Apr 2000 11:06:28 -0400
> I wrote a curses like terminal program on NCR SVR1. I thought printf
> was cool cause if I passed a null pointer to it, it didn't print
> anything, which was real convenient. Of course, the program space
> merely had a null byte at location 0. When we upgrade to SVR2, all
> hell broke loose. The program space now had an escape at location 0
> and random chars thereafter, so every place I printed a null pointer
> we got a random escape sequence sent to the terminal, with predictably
> unpredictable results. Oops!
For years we knew when we saw "p&P6" printed out somewhere a null pointer
was being used as a string. This combination of characters was part of
the crt0.o code that started every C program (a setd instruction plus
the code that setup the arglist and called main). Some time later some
yahoo decided it would be cute to put a zero at location zero which as you
noted masked all sorts of bugs. This was pretty prevelent in VAX code.
So much so that on the Gould SEL machines we used to work on, we had a
per excutable flag to supress the trap on location zero references, commonly
referred to as "brain dead vax compatibility mode" for the few apps that we
didn't want to hunt down and kill the null references in.
------------------------------
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, 05 Apr 2000 11:09:33 -0400
Ron Natalie wrote:
>
>
> NULL is necessarily an integer zero constant.
That's the C++ requirement, someone has pointed out that this thread has been
excessively
crossposted to include comp.lang.c, where a void* cast on the zero is legal (but in my
opinion was always expressly stupid and was primarily used to deal with functions with
indefinite args).
------------------------------
From: Dave Nejdl <[EMAIL PROTECTED]>
Subject: Re: Creating a new System Call
Date: Mon, 10 Apr 2000 02:06:01 GMT
Robert Lynch wrote:
> Dave Nejdl wrote:
> >
> > I am writing a kernel module and I want to create a *new* system call.
> > My knowledge is very shaky from here on, because I've been forced to
> > just study header files and such.
> > -First, I think I need to register my function in sys_call_table[], but
> > using what system call number? I see in asm/unistd.h that the last
> > system call is 190, is it safe to just put my function in
> > sys_call_table[191]?
> > /*is that all I have to do on the kernel end?*/
> > -To call the newly created system call from a user space program, can I
> > just call it?
> >
> > Thanks,
> > Dave Nejdl
>
> You might find some pointers in the example:
> ====
> /* syscall.c
> *
> * System call "stealing" sample
> */
>
> /* Copyright (C) 1998-99 by Ori Pomerantz */
> ...
> ====
> part of the "Linux Kernel Module Programming Guide", available for free
> on metlab, and wherever.
>
> HTH. Bob L.
> --
> Robert Lynch-Berkeley CA [EMAIL PROTECTED]
Thanks, thats a great example. And probly what I'll end up doing: steeling a
system call nobody ever uses:)
------------------------------
From: "Eddy" <[EMAIL PROTECTED]>
Subject: about share memory and semaphore
Date: Mon, 10 Apr 2000 11:48:00 +0800
I am using RH6.1 . Is it possible to config the share memory parameter and
semaphore parameter without recompiling kernel ?
Eddy
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Re: Partition Access
Date: Mon, 10 Apr 2000 05:00:06 GMT
A look at the 'df' command source might help
it returns disk blocks etc for all mounted partitions
still have nfs and samba to deal with though.
But to find out about all disks and partitions, I think
a trip to the proc is needed.
maybe a parsing of dmesg as it lists all devices not just
those used by the OS.
any hdx, sdx, and store that value.
Would keep from needing to look for drive controllers
directly.
Robert
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: type inconsistency in open(2)
Date: Sun, 9 Apr 2000 09:33:20 +0200
Weiguang Shi <[EMAIL PROTECTED]> wrote:
> Why should this be done?
One reason could be: Because int is the native format of the CPU.
Passing around other sizes as function argiments might generate bigger
and slower code.
If you use a char, the compiler might have to add separate and or
extension instructions without a real need for them.
So often programmers tend to pass values as int, even if only e.g.
char is needed.
--
Olav "Mac" W�lfelschneider [EMAIL PROTECTED]
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
EMACS: Do everything in one place.
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: Problem with PLIP, Update: It seems to be a kernel (parport?) problem
Date: 10 Apr 2000 05:39:23 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Ed Carp <[EMAIL PROTECTED]> writes:
> 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.
I think the laplink cable is o.k. like others pointed out, too.
> Alternateively, you could get a PCMCIA network card for your laptop if
> it supports PCMCIA.
This would cost a big part of the money i spent for this very old Laptop!
> BTW, this probably doesn't belong here - it's more of a networking
> problem ;)
Sorry, but i think i belongs exactly here, i even think it's a kernel
list issue:
I tried connecting my laptop to my Pentium PC instead of the Alpha.
It ran without any problem (it even was a piece of cake).
But that was with kernel 2.0.36. After upgrading the machine to 2.2.14
during this weekend, i have the same problem like i had with the Alpha.
So it seems to be a kernel problem.
I assume, there are incompatibilities with the driver when one side
is based on parport, the other side is not.
Has anybody out here managed to connect a linux 2.0.*
with a linux 2.2.* machine via plip?
Any ideas?
Martin.
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: "Eddy" <[EMAIL PROTECTED]>
Subject: delay start up for somve services
Date: Mon, 10 Apr 2000 13:37:14 +0800
I have installed sendmail , wu-ftpd, telnetd and httpd in my RH6.1.
Besides the httpd, all the service starts up very slowly. But after start
up, they works fine.
Say when I ftp from local machine (or from other machine), after it prompted
up "Connected to server", then it wait about 3 to 4 minutes to ask me the
login name. After I login, its transfer rate is fine. This situation same
for sendmail and telnet. But the http has no this problem.
Then I guess may be hardware has problem, but http works fine.
Do anyknow whats wrong here ?
Eddy
------------------------------
** 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
******************************
