Linux-Development-Sys Digest #267, Volume #8 Thu, 9 Nov 00 05:13:09 EST
Contents:
Re: mmap() vs. lseek() on /dev/mem ("Spam Me Not")
Re: non-portable port (Josef Moellers)
functions in the kernel ? ("mamyx")
Re: How to catch stdout of an application ? (denis martinez)
Re: What C++ compiler to use for dev if you don't want to give away ("D. Stimits")
Re: Software RAID ("Giampaolo Tomassoni")
bloody kernel.... ("�迵ö(Yung)")
Re: How to catch stdout of an application ? (Josef Moellers)
Re: bloody kernel.... (Josef Moellers)
Re: Is that process a thread? (Maciej Golebiewski)
2.4.0-test10: X on virtual console 8? (Mike Dowling)
Re: Is that process a thread? (Maciej Golebiewski)
----------------------------------------------------------------------------
From: "Spam Me Not" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: mmap() vs. lseek() on /dev/mem
Date: Thu, 09 Nov 2000 06:38:51 GMT
It doesn't work because /dev/mem explicitly disallows it:
from /usr/src/linux/drivers/char/mem.c:
static ssize_t read_mem(struct file * file, char * buf,
99 size_t count, loff_t *ppos)
100 {
101 unsigned long p = *ppos;
102 unsigned long end_mem;
103 ssize_t read;
104
105 end_mem = __pa(high_memory);
106 if (p >= end_mem)
107 return 0;
[snip]
This means that you can't read any values with physical addresses higher
than the largest physical
regular RAM address in the system. Most if not all bus addresses usually
are mapped above
the end of physical RAM in the system in most bus architectures, including
PCI.
You could write your own "/dev/mem"-like device that doesn't have this line
in it and it should probably
work fine. You may have to be careful about issuing memory barriers for
your device driver to work
correctly, depending on your particular CPU, chipset, and, device
characteristics.
Jeff Andre <[EMAIL PROTECTED]> wrote in message
news:8ucmtr$s3j$[EMAIL PROTECTED]...
> Gary Parnes ([EMAIL PROTECTED]) wrote:
> : Okay, I don't know what subtlety I'm missing here...
>
> : I'm trying to access kernel memory from user space. A simple way to
> : access kernel RAM is, of course, using lseek() on /dev/mem as root.
> : lseek'ing lets me browse the virtual memory space on an x86 box (from
> : 0xC0000000 up to end of RAM) quite nicely. But if I want to browse the
> : memory mapped portions of a PCI peripheral, I end up having to use
> : mmap() with the physical bus address of the PCI peripheral.
>
> : What I'm looking for is a common way to access both kernel RAM and PCI
> : memory space. The lseek technique doesn't seem to work in the PCI
> : memory space, and the mmap() technique doesn't seem to work in kernel
> : RAM space. I've tried playing with all sorts of permutations, but
> : nothing seems to work.
>
> : Why am I encountering problems?
>
> What problems are you having? As a debugging tool I'm about to write
> a read/llseek interface to a PCI's memory.
>
> --
> Jeff Andre
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Thu, 09 Nov 2000 08:54:54 +0100
George MacDonald wrote:
> =
> Josef Moellers wrote:
> >
> > George MacDonald wrote:
> > >
> > > T wrote:
> > > >
> > > > I'd like to revive an old dos project that used inline assembly c=
alls
> > > > to BIOS and direct screen writes. Trying to get up to speed with =
Linux
> > > > programming, I've been looking at some sources and reading what I=
can
> > > > find. It looks like both (BIOS calls and direct screen writes) ar=
e
> > > > verboten and in the domain of the Linux kernel. Learning about mo=
dules
> > > > and kernel will take too long although I plan to keep at it. I lo=
oked
> > > > at SVGALib, but my app doesn't need graphics-- it writes to text
> > > > screen. Are there any viable approaches (other than give it up:~)=
and
> > > > stuff like curses?
> > >
> > > Try
> > >
> > > man console_codes
> >
> > Just don't!
> =
> Hey dufus, read all of my posting(and understand it) before commenting.=
Perhaps
Sorry, the name's Josef and I prefer to be called that way (Alternatives
are "Herr M=F6llers", "Mr. M=F6llers", "M. M=F6llers", "M=F6llers-san", i=
n
another context "Sensei" might be acceptable, to name but a few). I did
use a real name in the "From" part, although umlauts are not supported.
> he wants to overlay graphics on top of what he is doing, or needs more
> fine grained control over the screen than ncurses allows.
> =
> Especially read my last line! i.e. the reference to the *value* of usin=
g
> ncurses!!!!!!!!!!! You never know how far and wide your program will be=
> used. One day all these X windows programs we use will probably be seen=
in
> full 3D immersive environments!
> =
> Also the program he is talking about may only be used by himself, in
> which case keeping things simple and easy to understand/implement is
> also a very important consideration!!!
Yes, that may very well be. And I apologize for not having valued your
entire article. However, to my defense, I would like to point out that
usually the first part of a message is more important than the later
parts. If I just saw your reference to console_codes and, more or less,
ignored your advice about ncurses, so might T. Also, if these things are
discussed in a newsgroup, others may pick up these concepts leading to
very badly written programs.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: "mamyx" <[EMAIL PROTECTED]>
Subject: functions in the kernel ?
Date: Thu, 9 Nov 2000 09:24:57 +0100
thanks for answering but I ve already answered why...
the kernel functions ? down_interruptible()? up()? they are not found in
details in books or docs and are hard to use (for me) ! how to use them ?
my question was:
are the IPC kernel functions ? (they re implemented in the kernel)
and the POSIX semaphores ? (sem_init(),sem_wait()....)
so
thanks
xavier
------------------------------
From: denis martinez <[EMAIL PROTECTED]>
Subject: Re: How to catch stdout of an application ?
Date: Thu, 09 Nov 2000 09:40:08 +0100
Thank's all for response,
I have thought about redirect the output into a file. But i'am working
with an embeded linux system and have only a flash disk wich not allow
me to write and write again. An alternative for me will be the use of a
ramdisk where i can create my files, but two problems appear:
1) I may not have enought memory free for that, i have to check that.
2) I have to control the size of my output files to avoid fulling my
ramdisk.
Thank's again, Denis.
--
Denis MARTINEZ <[EMAIL PROTECTED]>
R&D Engineer at Sofrel Telecontrol
Phone +33(0)4 92 08 43 24 Fax +33(0)4 92 08 43 19
------------------------------
Date: Thu, 09 Nov 2000 01:38:42 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What C++ compiler to use for dev if you don't want to give away
Kaz Kylheku wrote:
>
> On Wed, 08 Nov 2000 21:23:20 -0700, D. Stimits <[EMAIL PROTECTED]> wrote:
> >David Ball wrote:
> >>
> >> I'm looking to develop some small shareware programs for Linux, but I
> >> don't want to have to give out my source code. What C++ compiler can I
> >> use? It looks like gcc forces me to release everything under GNU GPL.
> >> Is that correct?
> >
> >I could be way off base, so take this with the proverbial grain of salt.
> >
> >If you statically bind libraries that are GNU into your project, then
> >you have to also follow the GNU licensing.
>
> Surely there is some exceptions for linking in run-time support provided by
> libgcc.a.
If you directly copy someone's code into yours, then you have to follow
their licensing. Run-time linking does imply non-static linkage, which
is NOT what the lib*.a files are good for. For all I know though,
libgcc.a might be licensed in such a way that it allows such a thing.
For one thing, since gcc/g++ compilers say that the code it generates is
itself not governed by their licensing, then probably anything that
gcc/g++ inserts, that it created and must run with, would be included in
the "unencumbered" definition (is it part of the compiler or is it
separate?). Imagine though that gcc/g++ accidentally made some third
party library become embedded in the compiler output...unless the
compiler owners had a right to say you are free to use its output, such
a statement wouldn't be entirely meaningful. I have no doubts at all
though that libgcc.a would be owned by the same entity that created
gcc/g++, just talking aloud here.
------------------------------
From: "Giampaolo Tomassoni" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Re: Software RAID
Date: Thu, 09 Nov 2000 08:39:44 GMT
"Jason from The Workshop" <[EMAIL PROTECTED]> ha scritto nel
messaggio news:[EMAIL PROTECTED]...
> redhat 6.2 lets you install on a software RAID partition.
> Redhat 6.1 does also now that I think of it and even has a nice GUI
frontend to
> create the partition. Its what I have been using for some time now, not
that raidtab
> is hard, but it sure beats installing, creating the array and then
migrating.
I tried it, but it seems you can create and install only raid0 devices, not
raid1.
6.1 has a button with (well, let me remember) I guess 'Raid partition' on
it. It creates 0xFD partitions, but I recall it wasn't completely working.
I don't remember the installation steps I followed, so I may be forgetting
something or even wrong. I recall I had to perform a manual raid1 activation
due to lack of sufficient support in both redhat versions.
Also other distributions (like Caldera and even the SuSe 1 ton cds) seem to
miss the point in raid1: none of them let create a raid1 device and install
there.
By the way, the reason is even simple: if you want to mirror the boot device
(like I everytime want) you'll find that lilo woun't install any boot
reference to /dev/mdX, because the MD device virtual-disk geometry is faked.
If you want to mirror the boot device, you have to stop raiding it, run lilo
on the 'true' device and, than, restart and reconstruct the raid. This is a
trick that probably is too much for many distributions.
Anyway, I believe that correctly supporting raid1 at install time is a must.
But other ways would be appreciated too, like the one available in a WinNT
environment: you specify an active partition on a disk and a free area on
another, click 'establish mirror' and that's all... Too easy.
Why shouldn't be the same on Linux? Are we wimp?
Regards,
--
======================================================
Giampaolo Tomassoni Information Systems Consultant
P.za 8 Aprile 1948, 4 Tel/Fax: +39-0578-21100
I-53044 Chiusi (SI) e-mail: [EMAIL PROTECTED]
ITALY
homepage: http://www.geocities.com/Eureka/Park/2209/
------------------------------
From: "�迵ö(Yung)" <[EMAIL PROTECTED]>
Subject: bloody kernel....
Date: Thu, 9 Nov 2000 17:49:07 +0900
Hi folks!!
I'm studying Linux kernel to figure it out by myself.
I knew it would be difficult but the more I try, the more I fall into
disorder. :-(
I have researched in the Internet and bought some famous books. But I
couldn't find the right way.
If you have experience in this area, please give me any advice.
I'd appreciate any advice you could give me.
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: How to catch stdout of an application ?
Date: Thu, 09 Nov 2000 10:09:35 +0100
denis martinez wrote:
> =
> Thank's all for response,
> =
> I have thought about redirect the output into a file. But i'am working
> with an embeded linux system and have only a flash disk wich not allow
> me to write and write again. An alternative for me will be the use of a=
> ramdisk where i can create my files, but two problems appear:
> 1) I may not have enought memory free for that, i have to check that.
> 2) I have to control the size of my output files to avoid fulling my
> ramdisk.
Another possibility that just springs to my mind is a named pipe. You
need to adapt your program, though, because it won't work as long as
noone is reading the other end. That way you may be able to attach to
the other end and listen to what the application has to say and when you
stop listening, the application has to ignore any errors and don't block
when writing.
YMMV,
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: bloody kernel....
Date: Thu, 09 Nov 2000 10:12:42 +0100
"=B1=E8=BF=B5=C3=B6(Yung)" wrote:
> =
> Hi folks!!
> =
> I'm studying Linux kernel to figure it out by myself.
> I knew it would be difficult but the more I try, the more I fall into
> disorder. :-(
> I have researched in the Internet and bought some famous books. But I
> couldn't find the right way.
> =
> If you have experience in this area, please give me any advice.
> I'd appreciate any advice you could give me.
You may want to start at a very simple level, e.g. take the (now
released) Lion's book on Unix. "It's only a few hundred lines of code"
(to quote an old friend), but it gives you a simple overview over what
the Unix (and Linux) kernel is all about. There is also a similar book
on Linux, but it would be a good idea to start with a very simple
kernel.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Is that process a thread?
Date: Thu, 09 Nov 2000 10:50:42 +0100
George MacDonald wrote:
>
> Maciej Golebiewski wrote:
> >
> > Not really! Consider this: you have a process A that in its main thread
> >
> > pthread_create (...) ---> creates thread that is a process B
> > fork () ---> forks process C
> >
> > Then /proc/#/maps for all A,B and C process (and the additional process which
> > is the thread manager for A) will contain libpthread. So following your logic
> > C would get classified as a thread for A (libpthread in maps nad PPID == A)
> > even though it was fork'ed and not pthread_create'ed!
> What is C then? If B was running in a thread context then so will C once it is
> forked, no? Unless it calls routines to "end" that thread. If it does terminate the
> "thread" will C then terminate the B thread?
I was sure that C is a separate process with no interference with lock/threads
created by A, but a few experiments have shown I'm wrong. I.e. C can call
pthread_detach on B and it will return no error, even though B should not be
known
to C (IMHO at least). Moreover, if there are mutexes, C will be able to lock
them only if they were unlocked at the moment of fork.
If C call pthread_kill on B (with SIGTERM for example), A, B and the thread
manager
will terminate, but C will keep running.
Funny, eh? I'm not sure how much of that is specific to linux implementation
of
pthreads... I wonder how does it look like on Solaris or other platforms...
> It looks like there is some cooperation required by the B process, it needs to
> behave properly? i.e. calling the right thread routines to fork/cleanup... So
>assuming
> it does then you are correct that the pthread lib is still in the newly
> forked childs mmap, even though it's not a thread!!! Grrrrrrrr
My point concerning the libpthread entry in maps was, that (at least
sometimes)
this entry will show up even if no thread functions are called, it is enough
for
the executable to have the pthread library linked to it. Therefore checking
this
entry does not mean the process is a thread.
> I wonder does anyone fork from a thread as you suggest? Even modfying the pthread
I do. Indirectly. I'm using a communication library (VIPL) that creates some
threads
for internal purposes. Sometimes in my program, which is the "main thread" I
need to fork. I run up to 4 instances of the program on a single machine (4
way SMP)
so you can imagine how ps output looks like :) and determining which
process/thread
is which can require some guesswork...
I used also to mix pthread_create and fork explicitly in one project, but
later
I dropped pthreads because the multithread version did not deliver as expected
(there was some hope that in some very specific cases having additional
threads
for async communication would speed up the app, but it did not work).
Maciej
------------------------------
From: [EMAIL PROTECTED] (Mike Dowling)
Subject: 2.4.0-test10: X on virtual console 8?
Date: 9 Nov 2000 09:53:53 GMT
ALT+8 is now where I find the X11 session instead of ALT+7.
The inittab hasn't changed for years, and there's no getty on tty7.
I've only seen this since I upgraded to test10 from test9.
It's not a problem, at least, it's not now that I know about it. It has
always been my habit to work in text mode if possible. For a while,
when I tried to return to X11 by changing to ALT+7, I thought that X11
was dead. I could see X11 processes running, and could not work it out.
Cheers,
Mike
--
My email address [EMAIL PROTECTED] above is a valid email
address. It is a mail alias. Once spammed, the alias is deleted, and
the integer 'N' incremented. Currently, mike[34,35] are valid. If
email to mikeN bounces, try mikeN+1.
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Is that process a thread?
Date: Thu, 09 Nov 2000 10:57:55 +0100
George MacDonald wrote:
>
> Maciej Golebiewski wrote:
> > I think that kernel will unlock all pages when all processes referencing
> > them die. IMHO it is the only reasonable thing for the kernel to do.
>
> For general purpose computing I agree, however in a constrained environment
> that is performing a dedicated function then it may make sense. For example
> quasi real time situations where a watch dog triggers the death of a process
> that is just going to be restarted again(perhaps after some other clean up).
It (locking shlib in mem) looks to me to be such a specialized feature that
there's no chance it could make it into the stock kernel. After all, if
a shared library is used by many programs, chances are that it'll be kept
in memory anyway, because you will have other processes using it and still
running. If the library is used only by a single program/process, than what's
the point of making it a shared library anyway?
> I agree with your approach, my question was more about the capabilities of
> Linux specifically. Can Linux lock pages in memory, either at the kernel
> level or in user land? Hmm, I think I'll go look at the code! How many
> times have I done that now!!!
man mlock
But I have no idea if, and how, you could use it to use it for locking shlib
(and I believe the kernel will unlock it automatically when the process dies).
Maciej
------------------------------
** 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
******************************
