Linux-Development-Sys Digest #407, Volume #8 Thu, 11 Jan 01 05:13:12 EST
Contents:
Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel. (Clifford Kite)
Pseudo Driver to hook onto input drivers (Paul Chiha)
Re: vm86 and virtual memory (Tim Roberts)
Re: The magic address 0x8048000 (Tim Roberts)
Re: how to get the pci device resources (Andrey Valik)
Re: about pci_find_device function (Andrey Valik)
mapping of shareable images ("Rob Eisink")
can't mount Solaris part. ("Oliver Kowalke")
Re: UNIX98 Pty's ???? ("Morten B�hmer")
Re: Extending /proc filesystem on Solaris 7/8? (Roger A. Faulkner)
About using ioctl() to get memory information (Chien-Hwa Hwang)
Re: Kernel -> user mode data tranfer ???? (Kasper Dupont)
Re: UNIX98 Pty's ???? (Kasper Dupont)
Re: The magic address 0x8048000 (Kasper Dupont)
Re: vm86 and virtual memory (Kasper Dupont)
Re: mapping of shareable images (Kasper Dupont)
Re: about pci_find_device function ("ShawnTsao")
----------------------------------------------------------------------------
From: Clifford Kite <[EMAIL PROTECTED]>
Subject: Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel.
Date: Wed, 10 Jan 2001 21:58:57 -0600
Gene Heskett <[EMAIL PROTECTED]> wrote:
> Gene Heskett sends Greetings to Jerry Peters;
> JP> Definitely not my pppd, which came from cs.anu.edu.au. It expects
> JP> everything in /etc/ppp. I would suspect a distribution customized
> JP> pppd. If the distro has changed the location of the config files,
> JP> then the distro should have changed the man pages accordingly.
> Jerry, I'd *almost* argue that point, because I'm quite sure I got that
> tar.gz from the .au site Clifford Kite gave me a few weeks back. Of
> course .au is a heck of a lot of square miles, so it might not have been
> the same site, but it most certainly was an aussie site I got it from.
> Is that the same site you gave me Clifford?
No. The site for the new 2.4.0 pppd source packages, and any later 2.4.x
pppd that Paul Mackerras generates, is linuxcare.com.au. The ANU site
only has the previous 2.3.x kernel series, unless there's a good hiding
place there that I haven't discovered.
But, again, there is no standard track ppp-2.4.1, it's got to be Red Hat
that generates that. Maybe it was a typo? Even when RH dithers an
original package, in the past it would have been named something like
ppp-2.4.0-1. There has been no change in the location of the secrets
files in the standard 2.4.0 either.
The way RH does configuration for connecting with pppd, and perhaps
also changing pppd to suit them, are covered by the "a distribution
thing" I mentioned. In order to make progress, changes must occur, but
not all changes are good. I think RH often does the Linux community a
disservice when it obfuscates configuration while attempting to ease the
transistion to Linux from MS (and thereby promote it's distribution in
the process).
--
Clifford Kite <kite@inet%port.com> Not a guru. (tm)
/* For every credibility gap, there is a gullibility fill.
-- R. Clopton */
------------------------------
From: Paul Chiha <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Pseudo Driver to hook onto input drivers
Date: Thu, 11 Jan 2001 15:49:37 +1100
A problem I need some help in:
I need to create some sort of way of reading various hardware inputs (which I
already have drivers for), and also simulating those same inputs through the
drivers to whomever has them opened.
So basically, I need to create something which sits on the driver->application
communication line, monitoring the information being passed, and also passing
it's own information.
I intend for this mechanism to not interfere with the current drivers (i.e. no
software change neccessary for these drivers).
If anyone can point me in a good direction, it'll be much appreciated
(email:[EMAIL PROTECTED]).
Thanks,
Paul
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: vm86 and virtual memory
Date: Wed, 10 Jan 2001 21:26:39 -0800
"Eppie" <[EMAIL PROTECTED]> wrote:
>
>I have an application complete with RTOS in it and it does not call
>any BIOS functions. I want to emulate that application in a virtual
>proces running under Linux.
You have a 16-bit real-mode RTOS? Code running in vm86 cannot switch to
protect mode.
There is a package called "lrmi" (Linux real-mode interface) that provides
kind of a wrapper around the vm86 syscall. It includes a sample program to
call into the VGA BIOS and even do a mode switch. I believe it is now
available on Sourceforge.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: The magic address 0x8048000
Date: Wed, 10 Jan 2001 21:30:58 -0800
Zhihui Zhang <[EMAIL PROTECTED]> wrote:
>
>The code of a process seems to start from some place around 0x800,0000.
>Why it does not start from virtual address 0? Is there a way to achieve
>this? Thanks for your help.
Why? What's the point?
One VERY GOOD reason for not starting at virtual address 0 is to eliminate
potential conflicts with the C null pointer. It is legal in C for a
compiler to define the null pointer as something other than 0, but there is
much code that assume the null pointer is represented by an all-zero word.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Andrey Valik <[EMAIL PROTECTED]>
Subject: Re: how to get the pci device resources
Date: Thu, 11 Jan 2001 11:40:21 +0500
Pete Zaitcev wrote:
>
> > if (pcibios_find_device( VENDOR_ID, DEVICE_ID, pci_index,&pci_bus,&pci_device) ==
>0 )
> > {
> > ...
> > pcibios_read_config_dword(pci_bus, pci_device, PCI_BASE_ADDRESS_0,&pci_ioaddr);
> > pcibios_read_config_byte(pci_bus, pci_device, PCI_INTERRUPT_LINE,&pci_irq);
> > ...
> > }
>
> Andrey, this is a bad idea if your code is ever to run on
> anything other than a desktop PC. This is especially true
> for IRQ number, which may be remapped. The right way to find
> PCI resources is to reference pci_dev structure.
>
> In other posting Shawn had a right example, except that he
> forgot to include necessary headers.
>
> -- Pete
Thanks, my code is run only on desktop PC, and I don't know
about this feature.
--
+----------------------+
| Andrey V. Valik |
| Papillon Systems |
|Mailto:[EMAIL PROTECTED]|
+----------------------+
------------------------------
From: Andrey Valik <[EMAIL PROTECTED]>
Subject: Re: about pci_find_device function
Date: Thu, 11 Jan 2001 12:01:00 +0500
Andrey Valik wrote:
>
> ShawnTsao wrote:
> >
> > Hi,
> >
> > i tried to find the hardware resource in module about irq, memory map...
> >
> > But i have a problem in my program during compiling
> > Is it right that i use the pci_find_device() to get the info about my
> > hardware?
> >
> > struct pci_dev *vdev;
> > .
> > .
> >
> > vdev = pci_find_device ( VENDOR_ID, DEVICE_ID, NULL); <----- (warning:
> > assignment makes pointer from integer without a cast)
> > .
> > .
> > Irq = vdev->irq <-----(error: dereferencing pointer to incomplete type)
> > .
> > .
> > .
> >
> > Thanks for your help
> >
> > Shawn Tsao
>
> my code:
>
> if (pcibios_find_device( VENDOR_ID, DEVICE_ID, pci_index,&pci_bus, &pci_device) == 0
>)
> {
> ...
> pcibios_read_config_byte(pci_bus, pci_device, PCI_INTERRUPT_LINE, &pci_irq);
> ...
> }
Sorry !
It's incorrect example, you need include <linux/pci.h>
to resolve your problem.
--
+----------------------+
| Andrey V. Valik |
| Papillon Systems |
|Mailto:[EMAIL PROTECTED]|
+----------------------+
------------------------------
From: "Rob Eisink" <[EMAIL PROTECTED]>
Subject: mapping of shareable images
Date: Thu, 11 Jan 2001 08:10:05 +0100
Hi,
I would like to know where the shareable images are mapped in (the start
virtual address) and the end va in the process. OS Linux
Are there any tools for this amd/or system calls to get this achieved?
thanks,
Rob
------------------------------
From: "Oliver Kowalke" <[EMAIL PROTECTED]>
Subject: can't mount Solaris part.
Date: Thu, 11 Jan 2001 08:52:20 +0100
Hi,
I've Solaris 7 (x86) on my system. My 2.4.0 linux kernel has support for
ufs, sun part. table, soalris part.table - but I'm not able to mount the
Solaris filesystem:
mount -t ufs -o ufstype=sunx86 /dev/hdb1 /mnt
How to fix?
Thanks,
Oliver
------------------------------
From: "Morten B�hmer" <[EMAIL PROTECTED]>
Subject: Re: UNIX98 Pty's ????
Date: Thu, 11 Jan 2001 09:07:15 +0100
Maybe I havn't explained my problem clear enough, or maybe I have miss
understood the whole problem.
When running commands like w/who/last and other utils
from the util-linux package, shouldn't it show that I'm logged
on to tty: pts/[0-9...] ????
Should not getty use the ptmx file to get a new tty?
--
Med vennlig hilsen/Best Regards,
Morten B�hmer - [EMAIL PROTECTED]
AdCo Partner AS
Bjellandveien 14 - 3172 VEAR
[EMAIL PROTECTED]
http://www.veggers.no
"Karl Heyes" <[EMAIL PROTECTED]> wrote in message
news:93ioua$rdg$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, "Eric" <[EMAIL PROTECTED]>
> wrote:
>
> > Morten B�hmer wrote:
> >>
> >> What should the inittab look like?
> >>
> >
> > I presume you mean the fstab.
> >
> > none /dev/pts devpts
> > gid=5,mode=620
> >
> > 0 0
>
>
> Just for completness, like proc don't use none, use devpts, it doesn't
> do anything in itself but if any errors come up then it won't
> identify the filesystem as none.
>
> karl.
------------------------------
From: [EMAIL PROTECTED] (Roger A. Faulkner)
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 11 Jan 2001 07:38:39 GMT
In article <[EMAIL PROTECTED]>,
Kaelin Colclasure <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
>> I don't think this argument really applies here. While I avoid Linux, I can't
>> remeber having seen versioning information in the /proc entries or
>> code numbers that allow for extension of the data stream. Just adding a
>> field will not work in some parse methods.
>
>This is true -- but the same criticism applies to the binary contents
>of the Solaris /proc entries, does it not? You may argue that application
>programs should be linking to libraries instead of reading directly from
>/proc, and I would agree with you. But how much of /proc is accessible
>that way today? (Not a rhetorical question -- I honestly don't know.)
I had been hoping to stay out of this discussion, but you have
impugned the engineering the Solaris /proc interface and I can't
let that slide.
The interfaces provided by /proc (documented in proc(4) and
defined by data structures and constants in <sys/procfs.h>)
form an Application Binary Interface (ABI) that remains
compatible from release to release. An application that uses
/proc and was compiled for Solaris 2.6 does not need to be
modified or even recompiled to continue to work the same on
Solaris 7, Solaris 8, and on into the foreseeable future.
Since Solaris 2.6, when structured /proc was introduced
(multiple files under each /proc/<pid> directory rather than
the old ioctl()-based interface [which incidentally still exists
and is source and binary compatible all the way back to Solaris 2.0]),
extensibility of the interfaces is achieved via several mechanisms:
- Existing structures contain pad fields for small additions
from time to time. Unused flag bits also exist.
- If space runs out, the structures can be extended by adding
members at the end because old programs read the old sizes
from the files and hence only get the information they expect.
- For large extensions, whole new files can be provided in
new releases.
- Control operations take unique control codes; new control
codes and their associated data structures can be created
in new releases for new process control functionality.
In short, the Solaris /proc interface was designed from the
outset to be binary compatible from release to release and
to be extensible when the need arises.
Roger Faulkner
[EMAIL PROTECTED]
------------------------------
From: Chien-Hwa Hwang <[EMAIL PROTECTED]>
Subject: About using ioctl() to get memory information
Date: 11 Jan 2001 08:33:55 GMT
Hi,
I have a question about using ioctl() function. I want to get memory
information like /proc/meminfo. But I don't want to call meminfo() to get
it. I want to use ioctl() to get thid information. Is it working?
If working, how do I use that? I have many problems when I use
ioctl() functions. Please answer me this question. Thanks.
Sincerely,
Jack.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Kernel -> user mode data tranfer ????
Date: Thu, 11 Jan 2001 08:44:39 +0000
byteme wrote:
>
> Looking for some suggestions on the best way to transfer a char string
>
> form a module to an awaiting user space proccess.
>
> The module should initiate the the communications.
>
> 1) Use put_user & then send the proc a SIG
>
> 2) Use AF_UNIX Socket with the proc listening on a port
>
> 3) Implement a Call Back function in the user proc. that the module
> can call.
>
> I've never had to do this where the module init's the COMM. any
> ideas out there
>
> thanx in advance
>
> kevin
What exactly do you mean by an awaiting user space process?
A process changes between user mode and kernel mode many
times when doing some work. Also notice that a waiting
process cannot be in user mode, to wait the process must
call the scheduler which can only happen in kernel mode.
If the process has requested some information by using a
syscall, you just have to use put_user and nothing else.
In that case your module is called as a function, when
you have written the string you return. It is not
different from a function call in any program.
If the process has requested the information, but it has
to sleep before the information arrives, you will have
to use a wait queue. The copying of the string cannot be
done by another process. The process must be waked up,
when it is awake it copy the string itself and then
simply returns.
If the process has not requested the information, you
cannot just use put_user. You can use either a signal
with a signal context or a filesystem object like a
socket.
It is posible to make a callback function, but that
would create a large security hole. Signals is the safe
alternative to callbacks.
If you give an example of how you would like the user
program to look I might be able to give a better answer.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: UNIX98 Pty's ????
Date: Thu, 11 Jan 2001 09:00:40 +0000
Morten B�hmer wrote:
>
> Maybe I havn't explained my problem clear enough, or maybe I have miss
> understood the whole problem.
>
> When running commands like w/who/last and other utils
> from the util-linux package, shouldn't it show that I'm logged
> on to tty: pts/[0-9...] ????
How did you logon to the system?
(X/console/rlogin/telnet)
What does w/who/last show you?
What does the tty command say?
>
> Should not getty use the ptmx file to get a new tty?
>
No *getty takes as argument the name of an existing
tty, that tty is a piece of code in the kernel that
communicate with external hardware. A pts is used
when a user space program wants to act as tty. When
a shell or other program tries to communicate with
the tty the communication does not go to external
hardware but through the kernel to the process that
created the pts. See figure
The situation when /dev/tty* is used.
+-------+ +------------+ +-----------+
| | +---+ | | Hardware |
| Shell |====|TTY| Kernel |====| eg Screen |
| | +---+ | | or Serial |
+-------+ +------------+ +-----------+
The situation when /dev/pts/* is used
+-------+ +------------+ +-----------+
| | +---+ | | |
| Shell |====|TTY| Kernel |====| xterm |
| | +---+ | | |
+-------+ +------------+ +-----------+
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: The magic address 0x8048000
Date: Thu, 11 Jan 2001 09:24:27 +0000
Tim Roberts wrote:
>
> Zhihui Zhang <[EMAIL PROTECTED]> wrote:
> >
> >The code of a process seems to start from some place around 0x800,0000.
> >Why it does not start from virtual address 0? Is there a way to achieve
> >this? Thanks for your help.
>
> Why? What's the point?
>
> One VERY GOOD reason for not starting at virtual address 0 is to eliminate
> potential conflicts with the C null pointer. It is legal in C for a
> compiler to define the null pointer as something other than 0, but there is
> much code that assume the null pointer is represented by an all-zero word.
> --
> - Tim Roberts, [EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.
Even if the code started at address 0 you would
place startup code at that point, then you would
not have to use pointers to 0. But having a page
mapped at address 0 would make it legel to
dereference 0 pointers which can make it harder
to locate bugs.
Also programs using vm86 needs to use the first
megabytes for another purpose and need to have
it free.
I cannot say why exactly 0x8048000 is being used
other than it is as good as anything else.
I think the address is written in the executable,
perhaps you can tell the assembler or linker to
generate code for another address.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: vm86 and virtual memory
Date: Thu, 11 Jan 2001 09:45:08 +0000
[EMAIL PROTECTED] wrote:
>
> Hi Kasper,
>
> Thanks for your source. I've received it yesterday and I tried it
> and it works great.
>
> Do you perhaps know how to write-protect a memory area (in the
> vertual prcoess)? I know there is a way to flag a memory region
> "read-only" or "execute". So, I can emulate ROM or a data-only area.
>
> Thanks again and regards,
> Erwin
You can do that with mprotect().
But you must notice that mprotect in itself is not enough.
When the memory is protected writes will cause a SIGSEGV
which must be caught and handled. (Otherwise you would get
a core dump)
Handling this sigsegv is not at all easy, basically you
have to emulate a single instruction by hand. I found a
trick however. The trick is to backup ROM, allow writing,
enable tracing, let code run, restore ROM, restore tracing,
disallow writing.
The tracing ensures that code will only run for one
instruction. Notice that instructions that would disable
tracing must be handled special.
The major disadvantage is overhead of copying ROM, in my
case I only need 16 bytes so I can live with that.
The great thing is that you can then make protection more
finegrained than the pagesize, and it is easier than
writing an entire CPU emulation.
But unfortunately there is a bug in the kernel, if the
stackpointer enters a protected page you will get an Oops.
In the latest versions of PCEMU I am using a 16512 KB
shared memory segment which I have mapped at different
addreses. Starting at 0 I do emulation using vm86, here
ROM is protected. At another address assigned in the usual
way I do whatever emulation is done in C code, and I
refresh the ROM before every entry to vm86().
Permitions for at page can be set to one of:
None
Read+Execute
Read+Execute+Write
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: mapping of shareable images
Date: Thu, 11 Jan 2001 09:47:39 +0000
Rob Eisink wrote:
>
> Hi,
>
> I would like to know where the shareable images are mapped in (the start
> virtual address) and the end va in the process. OS Linux
> Are there any tools for this amd/or system calls to get this achieved?
>
> thanks,
> Rob
Perhaps /proc/<pid>/maps and /proc/self/maps are
the files you are looking for.
--
Kasper Dupont
------------------------------
From: "ShawnTsao" <[EMAIL PROTECTED]>
Subject: Re: about pci_find_device function
Date: Thu, 11 Jan 2001 17:55:12 +0800
Hi
sorry, i forgot to write the header
#inlcude <linux/module.h>
.
.
#include <linux/modversions.h>
.
.
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/pci.h>
.
.
.
Thanks for your help
Shawn Tsao
Andrey Valik <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Andrey Valik wrote:
> >
> > ShawnTsao wrote:
> > >
> > > Hi,
> > >
> > > i tried to find the hardware resource in module about irq, memory
map...
> > >
> > > But i have a problem in my program during compiling
> > > Is it right that i use the pci_find_device() to get the info about my
> > > hardware?
> > >
> > > struct pci_dev *vdev;
> > > .
> > > .
> > >
> > > vdev = pci_find_device ( VENDOR_ID, DEVICE_ID, NULL); <----- (warning:
> > > assignment makes pointer from integer without a cast)
> > > .
> > > .
> > > Irq = vdev->irq <-----(error: dereferencing pointer to incomplete
type)
> > > .
> > > .
> > > .
> > >
> > > Thanks for your help
> > >
> > > Shawn Tsao
> >
> > my code:
> >
> > if (pcibios_find_device( VENDOR_ID, DEVICE_ID, pci_index,&pci_bus,
&pci_device) == 0 )
> > {
> > ...
> > pcibios_read_config_byte(pci_bus, pci_device, PCI_INTERRUPT_LINE,
&pci_irq);
> > ...
> > }
> Sorry !
> It's incorrect example, you need include <linux/pci.h>
> to resolve your problem.
> --
> +----------------------+
> | Andrey V. Valik |
> | Papillon Systems |
> |Mailto:[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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
