Linux-Development-Sys Digest #685, Volume #7 Fri, 17 Mar 00 11:13:18 EST
Contents:
Question about syslog() ("Brian")
Problem of Installing Red Hat " LI in LILO " ("Bass���v")
Re: Question about syslog() (Martin Gruber)
Re: Pseudo Tty ? (Jarkko Hakala)
Re: mmap PCI I/O registers (Juergen Hannappel)
Re: Absolute failure of Linux dead ahead? (Geoff Lane)
minor numbers/naming conventions for scsi-drives (Hartmut Steffin)
Re: Problem of Installing Red Hat " LI in LILO " (Daniel R. Grayson)
Linux kernel module on C++ ("Vadim Makhervaks")
Re: Absolute failure of Linux dead ahead? (The Ghost In The Machine)
Re: mmap PCI I/O registers ([EMAIL PROTECTED])
/dev/ttyS0 RTS/CTS problems (Mats Byggmastar)
Versioning Problem with binary modules (Stephane SARAGAGLIA)
Re: mmap PCI I/O registers (Juergen Hannappel)
Re: How to test a device driver (Alan Donovan)
Re: mmap PCI I/O registers (Alan Donovan)
Re: ACTIVE MEMORY EDITING...NEED HELP (Alan Donovan)
Re: Versioning Problem with binary modules (Alan Donovan)
----------------------------------------------------------------------------
From: "Brian" <[EMAIL PROTECTED]>
Subject: Question about syslog()
Date: 17 Mar 2000 08:17:20 GMT
I'm trying to write a message to the system log file. I thought it was
easy, but just couldn't get it done. Here is the test program:
#include <syslog.h>
int main(void)
{
syslog(LOG_INFO, "Hello, world\n");
return 0;
}
I've checked the file /etc/syslog.conf, and found the following setting:
*.info;mail.none;authpriv.none /var/log/messages
But I just can't find my message in /var/log/messages after I run the
program. The situation didn't improve if I added openlog() and closelog()
between syslog(). What have I missed anyway?
Brian
------------------------------
From: "Bass���v" <[EMAIL PROTECTED]>
Subject: Problem of Installing Red Hat " LI in LILO "
Date: Fri, 17 Mar 2000 16:37:50 +0800
I'm installing Rad Hat now
after the installation , It reboot and load LILO ..
but It stop with " LI " when loading LILO .
what is it ??
how to solve ?????
THX very much : )
------------------------------
From: [EMAIL PROTECTED] (Martin Gruber)
Subject: Re: Question about syslog()
Date: Fri, 17 Mar 2000 12:20:20 +0200
[Posted and mailed]
In article <8aspmg$d4h$[EMAIL PROTECTED]>,
"Brian" <[EMAIL PROTECTED]> writes:
> I'm trying to write a message to the system log file. I thought it was
> easy, but just couldn't get it done.
>
Die you check out the KERNEL_LOGLEVEL entry in your rc.config (SuSE) file?
This is usually set to 1 which means just to log serious messages. Setting
this entry to 7 could solve your problem.
Martin
------------------------------
From: Jarkko Hakala <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,comp.unix.sco.misc
Subject: Re: Pseudo Tty ?
Date: Fri, 17 Mar 2000 11:15:52 GMT
In article <[EMAIL PROTECTED]>,
"Jaron Chou" <[EMAIL PROTECTED]> wrote:
> Does anybody know how to add pseudo tty in Linux/Unixware/Unix SVR42
mkdev ptty
===================================
Jarkko Hakala <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Juergen Hannappel <[EMAIL PROTECTED]>
Subject: Re: mmap PCI I/O registers
Date: 17 Mar 2000 13:28:28 +0100
[EMAIL PROTECTED] writes:
> I have a device driver that uses mmap to allow an application to access
> some 8-bit PCI I/O registers (0x100 bytes). Read/write the registers
> works fine inside the driver (inb/outb), but the user application does
If inb/outb work the registers are in IO space, not in memory space,
so you cant access them with memory access funtions, hence the mmap()
doesn't help at all. Unless the PCI device offers a second view of its
rehister set in memory space or you could change the mapping of the
registers from IO to memory space you are lost there.
> not seem to have access via the address returned by my mmap. There are
> no failures or errors returned. The base address of the PCI region is
> low (0x2400). I use the following inside my mmap function:
>
> remap_page_range(vma->vm_start, (vma->vm_offset + map_addr), map_size,
> vma->vm_page_prot);
>
> where:
> map_addr = 0x2400; (physical address from PCI base_address array)
> map_size = 0x100;
>
> The address returned to the application makes sense (0x40014000), but
> certainly does not provide access to the registers. I tried adding
> PAGE_OFFSET to the map_addr as well, but no luck. Any clues?
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Dr. Juergen Hannappel Office: W148 Phone: +49 228 73 2447 FAX +49 228 73 7869
mailto:[EMAIL PROTECTED] Physikalisches Institut der Uni Bonn
http://lisa2.physik.uni-bonn.de/~hannappe Nussallee 12, D-53115 Bonn, Germany
CERN: Phone: +412276 76461 Fax: 77930 Bat. 892-R-A13 F-01631 CERN CEDEX, France
------------------------------
From: [EMAIL PROTECTED] (Geoff Lane)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 17 Mar 2000 11:59:05 +0000
In article <[EMAIL PROTECTED]>,
Bill Godfrey <[EMAIL PROTECTED]> writes:
> Use a standard library where time_t is a 64 bit signed integer (the new
> C standard requires such an integer type) and keep using C. No need to
> change languages.
There are many reasons to keep C out of inexpert hands ( and there's only
about 5 experts - three of whom devised the language!)
--
Geoff. Lane. | Linux has shown the world that Microsoft is only a local
Manchester | maximum; there are many, much higher mountains to be
Computing | climbed in this particular space.
If tennis elbow is painful, imagine suffering with tennis balls.
------------------------------
From: Hartmut Steffin <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: minor numbers/naming conventions for scsi-drives
Date: Fri, 17 Mar 2000 14:04:57 +0100
Hi there,
more than once I had trouble with the naming conventions of the
/dev/sd*. They are named sd[n][m], where n stands for the n-th found
disk, and m for a particular partition in sdn. sadly, n has nothing to
do with the scsi-id. so adding or removing a drive (or a drive failure)
cause all subsequent names to change, which obsoletes your fstab, and
you cry: "where is the boot disk?" do you see what i mean? this is not
what I call a system of high availibility.
there are other un*x systems, whose naming conventions are in a way they
never change, because they reflect the physical system. say
/dev/dsk/c[a]t[n]d[l]s[m] denotes to controler a, id n, lun l, slice m
(on a unixware slices system).
i wanted a likewise system. my idea was to mknod my own names on my
devices. but shock! even those names would not be static, as a change on
your scsi bus would make a change to the minor number as well!
quoting 'man sd'
... a minor device number of the form (16 * drive_number) +
partition_number, where drive_number is the number of the physical drive
in order of detection ...
this "in order of detection" gives me the headache.
you can find out about your drives after /proc is mounted and make your
nodes at this time. but this is too late in the boot process for your
fstab being right. any idea *not* involving a rewrite of sd.c?
regards
Hardy
------------------------------
Subject: Re: Problem of Installing Red Hat " LI in LILO "
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Date: 17 Mar 2000 08:09:41 -0600
"Bass���v" <[EMAIL PROTECTED]> writes:
> I'm installing Rad Hat now
> after the installation , It reboot and load LILO ..
> but It stop with " LI " when loading LILO .
> what is it ??
> how to solve ?????
> THX very much : )
>From the manual:
LI : The first stage boot loader was able to load the second
stage boot loader, but has failed to execute it. This can either be
caused by a geometry mismatch or by moving /boot/boot.b without
running the map installer.
First, try running lilo again from your install floppy.
------------------------------
From: "Vadim Makhervaks" <[EMAIL PROTECTED]>
Subject: Linux kernel module on C++
Date: Fri, 17 Mar 2000 16:27:20 +0200
Hi,
Can the linux kernel module be written on C++? I think that it should be
possible. What compilation and linkage options shall I use to build this
module?
Best regards,
Vadim.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 17 Mar 2000 14:58:51 GMT
In comp.os.linux.advocacy, Geoff Lane <[EMAIL PROTECTED]>
wrote on Fri, 17 Mar 2000 11:59:05 +0000 <9m6ta8.7kp.ln@twirl>:
>In article <[EMAIL PROTECTED]>,
> Bill Godfrey <[EMAIL PROTECTED]> writes:
>> Use a standard library where time_t is a 64 bit signed integer (the new
>> C standard requires such an integer type) and keep using C. No need to
>> change languages.
>
>There are many reasons to keep C out of inexpert hands ( and there's only
>about 5 experts - three of whom devised the language!)
Would you rather we rewrite the kernel in Fortran or COBOL? :-)
[.sigsnip]
--
[EMAIL PROTECTED] -- insert random misquote here
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: mmap PCI I/O registers
Date: Fri, 17 Mar 2000 14:45:32 GMT
Thanks for your response, I appreciate the help. After checking the raw
pci_dev value, the base_address of the register bank does have the LSB
bit set (indicating PCI_BASE_ADDRESS_SPACE_IO). It looks like I am out
of luck via mmap() for these registers? I will have to provide access
by implementing ioctl or read/write functions. There is another set of
registers that are double mapped into memory space as well as I/O space,
so these should be accessible via mmap(). More questions ... the
base_address of this second view is very high (0xc6bf0000), so I assume
I will need to remap this region via ioremap/vremap. Do I need to mask
off PAGE_OFFSET (i.e. via __pa()) first, before ioremap()? Then, for my
mmap() function, which address does remap_page_range() need, the raw
base_address, __pa(base_address), or the remapped address?
In article <[EMAIL PROTECTED]>,
Juergen Hannappel <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > I have a device driver that uses mmap to allow an application to
access
> > some 8-bit PCI I/O registers (0x100 bytes). Read/write the registers
> > works fine inside the driver (inb/outb), but the user application
does
> If inb/outb work the registers are in IO space, not in memory space,
> so you cant access them with memory access funtions, hence the mmap()
> doesn't help at all. Unless the PCI device offers a second view of its
> rehister set in memory space or you could change the mapping of the
> registers from IO to memory space you are lost there.
>
> > not seem to have access via the address returned by my mmap. There
are
> > no failures or errors returned. The base address of the PCI region
is
> > low (0x2400). I use the following inside my mmap function:
> >
> > remap_page_range(vma->vm_start, (vma->vm_offset + map_addr),
map_size,
> > vma->vm_page_prot);
> >
> > where:
> > map_addr = 0x2400; (physical address from PCI base_address array)
> > map_size = 0x100;
> >
> > The address returned to the application makes sense (0x40014000),
but
> > certainly does not provide access to the registers. I tried adding
> > PAGE_OFFSET to the map_addr as well, but no luck. Any clues?
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> Dr. Juergen Hannappel Office: W148 Phone: +49 228 73 2447 FAX +49 228
73 7869
> mailto:[EMAIL PROTECTED] Physikalisches Institut der Uni
Bonn
> http://lisa2.physik.uni-bonn.de/~hannappe Nussallee 12, D-53115 Bonn,
Germany
> CERN: Phone: +412276 76461 Fax: 77930 Bat. 892-R-A13 F-01631 CERN
CEDEX, France
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mats Byggmastar <[EMAIL PROTECTED]>
Subject: /dev/ttyS0 RTS/CTS problems
Date: Fri, 17 Mar 2000 16:10:11 +0100
Hello folks,
I'm working on some serial port code and have problems using
the RTS/CTS flow control. Opening, sending and receiving data
works fine but closing the port is problematic.
I have two machines, connected using COM1 (/dev/ttyS0)
running my program. Both programs are started and data is
sent and received. Then one of the programs closes it's
COM port. Now, when the other program tries to close it's
port, it just hangs on the close() call. It hangs until
the other program opens it's port again. It seems that close()
is waiting for a pin to go high until it returns. This is
strange as I open the port in nonblocking mode.
Is my setup code (attached below) bad or can there be some other
problems? The code is based on the "Serial Programming Guide for
POSIX Operating Systems". I am using Red Hat 6.1
Mats
==========
struct termios opt;
int mFD;
int open_flags = O_RDWR | // Read and write
O_NOCTTY | // Don't act on control characters
O_NDELAY; // Ignore DCD (Data Carrier Detect)
mFD = open("/dev/ttyS0", open_flags);
// Set nonblocking mode
fcntl(mFD, F_SETFL, FNDELAY);
// Get current settings
tcgetattr(mFD, &opt);
// Set line speed (115.2 k)
speed_t speed = B115200;
cfsetispeed(&opt, speed);
cfsetospeed(&opt, speed);
// Set number of data bits (8)
opt.c_cflag &= ~CSIZE;
opt.c_cflag |= CS8;
// Set parity (no parity)
opt.c_cflag &= ~PARENB;
opt.c_iflag &= ~INPCK;
// Set number of stop bits (1)
opt.c_cflag &= ~CSTOPB;
// Set flow contol (RTS/CTS)
opt.c_cflag |= CRTSCTS;
opt.c_iflag &= ~(IXON | IXOFF | IXANY);
// Enable receiver
opt.c_cflag |= CREAD;
// Do not change "owner" of line
opt.c_cflag |= CLOCAL;
// Set raw input
opt.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
// Disable input processing of characters
opt.c_iflag &= ~(INLCR | IGNCR | ICRNL | IUCLC);
// Set raw output
opt.c_oflag &= ~OPOST;
// Enable new settings
tcsetattr(mFD, TCSANOW, &opt);
===========================================
Mats Byggmastar, B.Sc., SW Design Engineer
GSM/GPRS/D-AMPS cellular data testequipment
Moesarc Technology AS, Oslo Norway
[EMAIL PROTECTED], tel: (+47)22516974
------------------------------
From: Stephane SARAGAGLIA <[EMAIL PROTECTED]>
Subject: Versioning Problem with binary modules
Date: Fri, 17 Mar 2000 16:24:58 +0100
Hi,
Sorry if my problem was already discussed in the past ;)
DESCRIPTION :
I have written a multimedia device driver for Linux (2.2.12-20).
Unfortunatly, this driver is not open source, and it is delivered
in binary format (xxx.o).
The problem is that when kernel version change, the module does
not load ("xxx.o kernell module version mismatch").
How can I do to make my binary module load whatever kernel
version is used ?
WHAT I UNDERSTAND ABOUT LINUX VERSIONING : (Please, tell me if
something is wrong)
1) Kernel can be used in two ways :
Enabeling versioning, an disabling versioning. You can
recompile it to change.
2) For modules, it is the same. If you compile them for a specific
kernel version, the module use symbol names of this version.
3) Most compiled Kernels are provided enabling versioning.
HOW I THINK I COULD RESOLVE MY PROBLEM
1) By providing a tool which scan the ksyms and my module symbols,
and replace the module symbol references with the new ones...
arg.... :(
2) By delivering with my binary module a open-source patch which could
be compiled on each Linux-system, and whose only task were to call
the kernel current system function. (Ex : In my binary module I call
"printk", and the patch in which is defined a function printk will
call the right printk_544984592090247606 function of the current
kernel). Then I think this patch could be linked to my binary module.
And the result could be loaded in the kernel. Am I right ?
3) Anybody knows the right way to do this job ?? ;)
Thanks to enlighten me...
Stephane SARAGAGLIA
------------------------------
From: Juergen Hannappel <[EMAIL PROTECTED]>
Subject: Re: mmap PCI I/O registers
Date: 17 Mar 2000 16:37:36 +0100
[EMAIL PROTECTED] writes:
> Thanks for your response, I appreciate the help. After checking the raw
> pci_dev value, the base_address of the register bank does have the LSB
> bit set (indicating PCI_BASE_ADDRESS_SPACE_IO). It looks like I am out
> of luck via mmap() for these registers? I will have to provide access
> by implementing ioctl or read/write functions. There is another set of
> registers that are double mapped into memory space as well as I/O space,
> so these should be accessible via mmap(). More questions ... the
> base_address of this second view is very high (0xc6bf0000), so I assume
> I will need to remap this region via ioremap/vremap. Do I need to mask
No, you neet the ioremap() only for acces from kernel space, to access
from user space you do the ordinary remap_page_range().
> off PAGE_OFFSET (i.e. via __pa()) first, before ioremap()? Then, for my
> mmap() function, which address does remap_page_range() need, the raw
> base_address, __pa(base_address), or the remapped address?
--
Dr. Juergen Hannappel Office: W148 Phone: +49 228 73 2447 FAX +49 228 73 7869
mailto:[EMAIL PROTECTED] Physikalisches Institut der Uni Bonn
http://lisa2.physik.uni-bonn.de/~hannappe Nussallee 12, D-53115 Bonn, Germany
CERN: Phone: +412276 76461 Fax: 77930 Bat. 892-R-A13 F-01631 CERN CEDEX, France
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: How to test a device driver
Date: Fri, 17 Mar 2000 15:40:04 +0000
Ron Reeder wrote:
> I just tried to do a make after downloading the examples from
> www.ora.com website. No got... Lotsa compiler warnings because I guess
> they've moved to using lotsa typdefs (instead of just int) and the
> current struct... is now a macro pointing to a function call. The code
> WAS only tested on 2.1.x kernls and I was attempting to compile under RH
> 6.1 2,2.12-20
I don't wish to point out the obvious, but I fell into this trap: the
samples from the ORA website are for pre 2.1 kernels, but they contain a
directory called v2.1 which has the updated code in. You need to compile
this, as the old stuff won't work any more.
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: mmap PCI I/O registers
Date: Fri, 17 Mar 2000 15:44:07 +0000
[EMAIL PROTECTED] wrote:
>
> After checking the raw
> pci_dev value, the base_address of the register bank does have the LSB
> bit set (indicating PCI_BASE_ADDRESS_SPACE_IO). It looks like I am out
> of luck via mmap() for these registers? I will have to provide access
> by implementing ioctl or read/write functions.
Yep.
> There is another set of
> registers that are double mapped into memory space as well as I/O space,
> so these should be accessible via mmap().
Yes -- typically both are available. The definitive Mindshare book on
PCI says that new cards should offer memory-mapped regs plus optionally
regs in IO space, as IO space is densely populated these days, and also
some PCI systems don't use IO space.
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: ACTIVE MEMORY EDITING...NEED HELP
Date: Fri, 17 Mar 2000 15:48:33 +0000
Syntax wrote:
>
> I wish to learn how to edit memory in a active process...
> basically this is my goal..
If you wish to write a debugger, look at man ptrace(2) and the source
for gdb. A debugger has complete control over the process being debugged
(but not others).
> printf("%d\n",x);
>
> i want to find the memory address in memory and change the value of x so
> that it will print a different number. while the program is running of
> course. basically a very simple beginning to a "program trainer"
This is relatively simple with ptrace (you still need to know about
symbols, object files, and ld.so, the dynamic linker). /dev/kmem and
/proc/kcore are useful for kernel debugging (which I know little about).
For usermode debugging, stick with ptrace.
HTH
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: Versioning Problem with binary modules
Date: Fri, 17 Mar 2000 15:57:18 +0000
Stephane SARAGAGLIA wrote:
> Sorry if my problem was already discussed in the past ;)
>
> DESCRIPTION :
> I have written a multimedia device driver for Linux (2.2.12-20).
> Unfortunatly, this driver is not open source, and it is delivered
> in binary format (xxx.o).
Binary drivers are discouraged because:
1) as you state, they are resistant to kernel changes. This is
important, because Linux's most important feature is the ease and speed
with which the kernel is/can be improved. Many times has the interface
to drivers been broken, driver-writers extra effort being justified by
general "progress" of the OS as a whole. Binary driver distributers will
lose this one.
2) drivers generally access hardware. If you need to sell something as a
company, sell the hardware not the software that it requires. There's a
certain elegance to the argument that things that take per-unit effort
to create should cost money [i.e. hardware], but one-off efforts are
free [i.e. software].
> HOW I THINK I COULD RESOLVE MY PROBLEM
> 1) By providing a tool which scan the ksyms and my module symbols,
> and replace the module symbol references with the new ones...
> arg.... :(
No: the semantics of functions might change. Or functions might
disappear altogether. It has happened.
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
** 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
******************************
