Linux-Development-Sys Digest #576, Volume #8 Mon, 19 Mar 01 04:13:09 EST
Contents:
HMMM! (Josef Allen)
Volunteer Board Members Wanted for the Plex86 Software Foundation ("Keith Donaldson")
Re: !! Filename and Pathname problem !!! ("Ross Crawford")
problem debugging (Rud)
Re: HMMM! ("Joseph A. Knapka")
Re. Hmm (Josef Allen)
System call proposal: plock()? (John Kelly)
usb backport to 2.2.14 (Mike Rheinheimer)
Using bzdisk as a boot disk question. (ImperatorM)
Re: Using bzdisk as a boot disk question. (John Kelly)
Re: help,still confused about the boot of the linux system?? (Josef Moellers)
Re: problem debugging (Josef Moellers)
Re: System function interrupts (Andrzej Stypula)
Re: 4GB memory limit (Kasper Dupont)
Re: preloading into ramfs (Kasper Dupont)
----------------------------------------------------------------------------
From: Josef Allen <[EMAIL PROTECTED]>
Subject: HMMM!
Date: Sun, 18 Mar 2001 15:44:59 -0500
In reading this book it seems to me that I may have not fully understood
what a driver is.
I have a micro controller that I am going to communicate with via the
serial port (i.e. I will attempt to send an electrical pulse to the
microcontroller)
Something tells me that this is not a driver.
For clarification is it possible that I have to write another serial port
driver to talk to the microcontroller?
This would mean that I would definitely have to write it in C
I have bought that book on device drivers and I do not see where it says
that the driver has to be apart of the kernel (Not that I doubt it)
Hey Do you know if there is a way to definitly confirm the fact that I
have to make it module
Josef D. Allen
On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:
> OK, Josef, it appears to me from your previous post that you probably are
> not talking to the hardware via your Linux program, but only through your
> windows program.
>
> Now, the fact that you can compile it is good. I would look carefully at the
> need for the windows.h include as that might have some side affects in the
> Linux environment. Now the next thing is to determine if you are truly
> talking to your hardware in your Linux machine. I believe (and others can
> jump down my throat if I am wrong) that you need to load your program as a
> module using insmod in order to be able to access the uart hardware. See
> Alexander Rubini's book "Linux Device Drivers" for the details on on the
> care and feeding of modules including the startup code in init_module, the
> cleanup code in cleanup_module and the meaning of the compile time option
> __KERNEL__ to access portions of header files for device drivers.
>
>
>
>
>
------------------------------
From: "Keith Donaldson" <[EMAIL PROTECTED]>
Subject: Volunteer Board Members Wanted for the Plex86 Software Foundation
Date: 18 Mar 2001 21:12:42 GMT
Volunteer Board Members Wanted for the Plex86 Software Foundation
The Organizing Committee of the Plex86 Software Foundation is looking for a
few talented and diligent volunteer board members to help us provide
organizational, legal, and financial support for Plex86 open-source software
projects (www.plex86.org).
The goal of the Plex86 project is to create an extensible open source PC
virtualization software program that will allow PC, and workstation users to
run multiple operating systems concurrently on the same machine. What makes
it challenging on the PC, is that the x86 processor is not "naturally"
virtualizable. That is to say, it was not designed to run multiple operating
systems concurrently. However, with some manipulation and use of system
level features, this can be done. The Plex86 environment makes the processor
virtualization more flexible and controllable than commercial products where
developers do not have access to the source code, such as VMware.
If you can contribute one evening a month and have skills or contacts that
can aid us in the management of funds, intellectual property, accounting,
publicity, fundraising or allocation of resources to projects, please
contact Keith Donaldson at 617.576.9555 or [EMAIL PROTECTED] to find out more
about whether this volunteer opportunity is right for you.
kd
------------------------------
From: "Ross Crawford" <[EMAIL PROTECTED]>
Subject: Re: !! Filename and Pathname problem !!!
Date: Mon, 19 Mar 2001 10:05:34 +1100
man basename
man dirname
HTH
ROSCO
Karim A <[EMAIL PROTECTED]> wrote in message
news:992h2q$3dq$[EMAIL PROTECTED]...
> Hi all,
>
> where, I've to developp a linux application module for my job and I need a
> function that maniplautes filenames and pathname.
> Let me explain you my problem:
>
> under windows, there is win32 function called splitpath().
> this functiontakes a pathname as first parameter (i.e.
> c:\myapps\projectx\myapps.cxx)
> and the functions retrieves the driver name, the directory, the file title
> and the file extension (if any).
>
> I really need a function such like this one for linux / unix.
>
> in fact, i may have to code it manually but i've short deadlines and i
can't
> take the time to write one perfectly and to test it.
> I just need to retrive the file title from a full path name.
>
> Can somebody help me please ?!!
>
>
> Thanks a lot.
>
> Regards,
>
>
> Karim
>
>
>
------------------------------
From: Rud <[EMAIL PROTECTED]>
Subject: problem debugging
Date: Sun, 18 Mar 2001 19:06:43 -0800
I all what is the proper way for debugging a running process and
find out where the application
have stop and to correct the problem
thanks
------------------------------
From: "Joseph A. Knapka" <[EMAIL PROTECTED]>
Subject: Re: HMMM!
Date: Mon, 19 Mar 2001 00:45:34 GMT
Josef Allen wrote:
>
> In reading this book it seems to me that I may have not fully understood
> what a driver is.
>
> I have a micro controller that I am going to communicate with via the
> serial port (i.e. I will attempt to send an electrical pulse to the
> microcontroller)
> Something tells me that this is not a driver.
A "driver" is a piece of kernel code that controls a piece of
hardware directly connected to the system on which the kernel
is running, and makes that hardware available to user programs
through a standardized API. So you need a driver to control the
16550 UARTs in the on-board serial ports, and Linux, naturally,
has such drivers.
Your application does not require a kernel driver. Rather, it
will use the facilities provided by the existing serial
driver code. All you need to do is understand the protocol
by which you will communicate with the microcontroller,
and write code that uses the open(), read(), write(), and
(possibly) select() or poll() system calls to send and receive
data on the serial port.
HTH,
-- Joe Knapka
"It was just a maddened crocodile hidden in a flower bed. It could
have happened to anyone." -- Pratchett
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. *
------------------------------
From: Josef Allen <[EMAIL PROTECTED]>
Subject: Re. Hmm
Date: Sun, 18 Mar 2001 21:47:24 -0500
1.When you say can I communicate with my program via a serial terminal
program, I am unsure as to what you mean.
If you mean, If I could send a byte of information out on a line and
then retrieve that info back then Yes.
2.However my plans are to sooner or later turn this program into a
realtime project.
3.When you say plain text or binary could you please explain
What I am trying to do is to send a byte of data out through the serial
port that will first initialize the comport hardware (i.e uart I think)
to the following: (9600, N, 8, 1, no IRQ's). After this happens the
program will generate a hardware reset pulse. Then after that happens
the program will take a byte of data to each module in the network in
order to find out how many modules are on the network. I was trying to
do this all using the outb and inb function.
The reason for this was
A. I was trying to mimic what the original implementor was doing
without changing to much.
B. I wanted to use those functions that would allow me the most control
i.e. realtime
C. I had no other clue.
I have been trying to work on this since October of last year.
It took me 2 months to figure out what outp meant in the windows program.
After that I just thought it would be a cinch to re-write that driver
Well HA HA.
After all this the first thing is I just want it to work.
Secondly, I want to learn as much as possible therefore I feel
learning how to make it apart of the kernel will allow me to learn more.
NO GUTS NO GLORY
I am unsure what xc means.
I hope that I have answered your questions
Josef D. Allen
On Sun, 18 Mar 2001 [EMAIL PROTECTED] wrote:
> Well, Josef, let me try a couple of questions. The first is, can you
> communicate with your microcontroller via a serial terminal program. If so,
> you can obviate the need for a driver and just use say xc, which is a serial
> terminal program that you can find in source form, modify if need be to add
> special commands for your micro that may be say not plain text ascii. That
> direction might get you past the need for a driver. The second is, if you
> have some real-time need, like you need to communicate every 100ms with your
> hardware. If that is true, then you would need to insert your code into the
> kernel in some fashion. Anyway, try giving me a more complete idea of what
> you are trying to accomplish in terms of commands (plain text or binary),
> real-time needs (do you need deterministic time slicing for communications
> or can you live with what the kernel is providing to a serial communications
> program).
>
>
> ----- Original Message -----
> From: "Josef Allen" <[EMAIL PROTECTED]>
> Newsgroups: comp.os.linux.development.system
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, March 18, 2001 12:44 PM
> Subject: HMMM!
>
>
> > In reading this book it seems to me that I may have not fully understood
> > what a driver is.
> >
> > I have a micro controller that I am going to communicate with via the
> > serial port (i.e. I will attempt to send an electrical pulse to the
> > microcontroller)
> > Something tells me that this is not a driver.
> >
> > For clarification is it possible that I have to write another serial port
> > driver to talk to the microcontroller?
> >
> > This would mean that I would definitely have to write it in C
> >
> > I have bought that book on device drivers and I do not see where it says
> > that the driver has to be apart of the kernel (Not that I doubt it)
> >
> > Hey Do you know if there is a way to definitly confirm the fact that I
> > have to make it module
> >
> > Josef D. Allen
> >
> > On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > > OK, Josef, it appears to me from your previous post that you probably
> are
> > > not talking to the hardware via your Linux program, but only through
> your
> > > windows program.
> > >
> > > Now, the fact that you can compile it is good. I would look carefully at
> the
> > > need for the windows.h include as that might have some side affects in
> the
> > > Linux environment. Now the next thing is to determine if you are truly
> > > talking to your hardware in your Linux machine. I believe (and others
> can
> > > jump down my throat if I am wrong) that you need to load your program as
> a
> > > module using insmod in order to be able to access the uart hardware. See
> > > Alexander Rubini's book "Linux Device Drivers" for the details on on
> the
> > > care and feeding of modules including the startup code in init_module,
> the
> > > cleanup code in cleanup_module and the meaning of the compile time
> option
> > > __KERNEL__ to access portions of header files for device drivers.
> > >
> > >
> > >
> > >
> > >
> >
>
Josef D. Allen
------------------------------
From: John Kelly <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: System call proposal: plock()?
Date: Sun, 18 Mar 2001 20:17:02 -0700
I think what I need is a new system call that could be used to implement
the Solaris command plock. I want to be able to spawn a process and
lock it in memory externally--basically do what sys_mlockall() does,
only with the addition of a pid_t parameter. I know it's possible to
hack to source of the processes that we don't want swapped, but many of
those aren't under my control--and in any case, a "plock" would be great
for investigations and emergency fixes.
I'm figuring I'll crib the task_struct look-up from signal.c's
kill_proc_info() and then run a version of do_mlockall() that uses this
task_struct* rather than 'current'?
Sound OK?
What would be the right approach to campaign for inclusion in the base
kernel if I'm successful?
Any thoughts appreciated.
-jk
------------------------------
From: Mike Rheinheimer <[EMAIL PROTECTED]>
Subject: usb backport to 2.2.14
Date: Mon, 19 Mar 2001 04:07:00 +0000 (UTC)
Hi all. I am in a situation where I need to backport usb to 2.2.14. I
personally think this is a bad idea and have expressed this opinion over
and over to the powers that be, but alas, this is the situation. No
backport patch file exists for such a situation. So far the suggestions
I have recieved have been to copy the usb stuff from 2.2.18 to the 2.2.14
kernel and work it from there...and that this should be relatively easy.
Well, it is not easy. I have tried several methods, including, but not
limited to:
1. straight copy of drivers/usb from 2.2.18 to 2.2.14. Then set the usb
options I need to compile in and copy the files I need as I find
errors. This seems to be an extraordinarily tedious process, as I
have to wait for a compile error each time I copy in a new (2.2.18)
file.
2. patch the 2.2.16 kernel with the usb patch at www.linux-usb.com and
use it to patch the 2.2.14 kernel in the same manner as #1. Same
tedious problem.
3. try to use diff to generate a patch file between the already-patched
2.2.16 kernel and the 2.2.14 kernel. When I do this, I always find
something that is missing when I compile. Often it's an error in an
area I'm not trying to patch, like block devices.
Does anyone have any suggestions or methods of attack to go about solving
this problem? Why would I be told that it should be easy to port the
2.2.18 usb stuff to the 2.2.14 kernel?
If this questions is better suited for another newsgroup, please let me
know. Thanks in advance...
Mike
--
"Opportunity is missed by most people because it is dressed in
overalls and looks like work." -- Thomas Edison
------------------------------
From: [EMAIL PROTECTED] (ImperatorM)
Date: 19 Mar 2001 04:49:41 GMT
Subject: Using bzdisk as a boot disk question.
I have made a boot disk with make bzdisk but it won't boot because I need to
tell it where root is. How do I do this? Also, is using a disk made this way
a good way to boot regularly? Everything I read reffers to using bzdisk to
test a kernel, I use a LILO disk now so is there really any difference? Thanks
-Ted
------------------------------
From: John Kelly <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Using bzdisk as a boot disk question.
Date: Sun, 18 Mar 2001 22:30:42 -0700
ImperatorM wrote:
> I have made a boot disk with make bzdisk but it won't boot because I need to
> tell it where root is. How do I do this?
rdev /dev/fd0 /dev/hda(root partition)
> Also, is using a disk made this way
> a good way to boot regularly? Everything I read reffers to using bzdisk to
> test a kernel, I use a LILO disk now so is there really any difference? Thanks
I use lilo to boot regularly because it's faster, but it's good to have a boot
disk when you're testing a new kernel, in case you overwrite your only working
kernel, or forget to run lilo.
Typically, I make a boot disk just before embarking on those adventures.
(mkbootdisk on a RH system)
>
> -Ted
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: help,still confused about the boot of the linux system??
Date: Mon, 19 Mar 2001 08:35:11 +0100
hushui wrote:
> =
> Hi folks:
> I am still confused about the boot of the linux system??
> 1.Is bootsect.S and setup.S are only needed in boot with floppy??
> But they are compiled and linked in the kernel image file.
I assume they are added to the kernel image for convenience reasons: one
image for floppy and hard disk boot.
> 2.read 512bytes (which is MBR) is done by BIOS POST program??
yes.
> 3.If lilo is installed in mbr (hda2 is linux's / , hda1 is msdos,and th=
e
> active partion is hda1) then why not BIOS boot the active partion of m=
sdos
> partion directly ?? Is it because lilo program which select which parti=
on to
> boot ,
> so the active mark in the partion table is no use??
The BIOS will not boot the active partition, but the code in the MBR.
Since LILO handles this differently, you can boot a DOS partition, but
this is not done by "marking it active", but by setting it up as a
bootable item (in /etc/lilo.conf) and selecting it at the lilo prompt.
The "original" boot loader in the MBR will select the "active partition"
and load that partition's Partition Boot Record which will then read in
thyt partition's OS (or OS Loader or whatever).
Installed in the MBR, LILO (its "first stage") will load the "second
stage loader" from the /boot/boot.b file which will load some vmlinuz or
the old MBR code from boot.xxxx, where xxxx is the Linux device number
of the device which originally held the MBR.
-- =
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: problem debugging
Date: Mon, 19 Mar 2001 08:49:30 +0100
Rud wrote:
> =
> I all what is the proper way for debugging a running process and
> find out where the application
> have stop and to correct the problem
Have you looked at gdb?
Also, strace is sometimes helpfull to check roughly what an application
is doing.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
From: Andrzej Stypula <[EMAIL PROTECTED]>
Subject: Re: System function interrupts
Date: Mon, 19 Mar 2001 09:16:49 +0100
"Joseph A. Knapka" wrote:
>
> Andrzej Stypula wrote:
> >
> > Hi everyone,
> > I have a little problem in below situation.
> > lets consider an example code (standard handler for SIGALRM - return):
> >
> > _Time(timelimit);
> > err=any_system_function_in_blocking_mode(...);
> > _Time(0);
> >
> > the 'timelimit' is about 10 - 50 ms.
> >
> > the thread or process has slept by scheduler after doing the
> > _Time() but before any_system... (is possible?)
> >
> > After timelimit proces got SIGALRM, but process which is running now
> > has hihgher priority, so my process sleep longer.
> > Now, the Q:
> > the any_system... returns with EINTR or my process would be sleep
> > forever?
>
> The next time your process is chosen by the scheduler, the kernel
> will deliver the SIGALRM. You will definitely not sleep forever
> - in fact you don't sleep at all. Being evicted from the CPU due
> to another process being scheduled is -not- the same as sleeping.
> If another process is scheduled, your process is still in the
> "runnable" state, not the "sleeping" state.
As I well anderstand you, the 'any_system_fuction_in_bloking...'
always returns with EINTR error if the timelimit will be too short.
So,I have not to use any extra magic code to prevent process (thread)
for deadlock.
--
Andrzej Stypula @Home: altair.krakow.pl
[EMAIL PROTECTED] Private Home Domain, Poland
PGP2.x id: 9AB243A5 ####################################################
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: 4GB memory limit
Date: Mon, 19 Mar 2001 08:41:05 +0000
Ryan Storgaard wrote:
>
> Hi all,
>
> I am running the 2.4 kernel, and originally compiled support for 64GB of
> memory and then put 6GB of RAM in the box. Linux ran fine, but I have an
> application (unfortunately I'm not at liberty to say what application) that
> upon install said "error, you have support for more than 4GB of RAM". I had
> to recompile with support for only 4GB of RAM and everything went fine. I
> really need this application to support more RAM though.
Is it an application or a kernel module that does not
support more than 4GB of memory?
If it is an application there is no problem at all,
from the applications point of view everything works
exactly the same way.
If it is a kernel module there might be problems, I
think in most cases it would be enough to recompile
the module.
>
> I'm a sys engineer, not a programmer, so I need some of your insight...
>
> If an application was originally developed to support 4GB of RAM, what is
> involved in order to allow it to handle more than 4GB? ( I mean in
> general... is it a simple switch or parameter during the compiling of the
> application or is it a complex rewrite of the entire application ....)
>
> Excuse my programming incompetence and the reference to windoze but in NT,
> for example, NT tells every app that it has access to 4GB of RAM... What
> does linux do (in the 2.4 kernel)?
>
> Reason I ask is because the vendor mentioned it wasn't planning on
> supporting more than 4GB of RAM with Linux, and to look for their Windows
> 2000 version to support larger amounts of RAM.... I REALLY don't want to go
> down that road because that would mean I would have to purchase Win2k
> DataCenter Server to handle the RAM... I want to use Linux.
>
> cheers,
>
> ryan
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: preloading into ramfs
Date: Mon, 19 Mar 2001 09:06:19 +0000
[EMAIL PROTECTED] wrote:
>
> I previously wrote an init program for advanced CD booting. It was the
> only file in initrd, it set up ramfs, found the boot CD, mounted the CD,
> loaded a tar file into ramfs, and pivoted the ramfs to be the root fs.
> This expanded the limits of what can be loaded in ram from a CD to the
> lesser of your available ram or the CD space to put the tar file. It
> could have even used compression, though I didn't go that far this time.
>
> What I am thinking about now is a similar thing for a hard drive based
> system. Part of the idea came from seeing how the Ascend GRF-400 router,
> which was FreeBSD based, loaded everything from flash RAM. My idea is
> to have the partition which the kernel initially mounts read-only as
> root contain /dev/console and /sbin/init which will have my init code.
> My code will then set up the ramfs, find the files to be preloaded, then
> pivot the ramfs to be the root fs and execve() to the loaded /sbin/init.
> The source files to be loaded could come from a number of places, such
> as the same partition or a different one, and as a tree of files or as a
> tar file.
>
> There are a couple of intentions that get me thinking about this.
>
> One thought is that some things would just be faster if they are in ram,
> and this is one sure way to get them in ram. Given that many systems
> have a lot of ram these days, loading 8 to 32 meg of stuff into ram
> wouldn't be all that much of a hit. It would depend on the judgement of
> the administrator if they want to take advantage of it, and just how much.
I wouldn't expect much gain, I would expect the frequently used files
to reside in cache.
>
> Another thought is a simple layer of security aspect to it. While it sure
> won't be resistant to sophisticated attacks, many times the holes the
> crackers do find somewhere aren't big enough for anything but very trivial
> initial attacks.
I don't see how this would create any new security holes. Of course you
must use proper permitions, the image from which you fill the ramfs
must not be readable or writeable by anybody but root.
>
> And this could surely help prevent some disasterous accidents where critical
> system startup files get clobbered. If the ram preload alone can get the
> system up, networked, and running sshd, then anything else that can be
> repaired remotely, or possibly even automatically repaired.
That will surely minimize the risk of disasters. If in addition you
choose to keep your image on a partition that is usually only mounted
read only, you will be very good protected. Whether /boot or another
partition is most appropriate probably is a question about taste.
>
> What are you thoughts on this?
>
> I was looking at how ramfs was implemented, and am left wondering if there
> are any issues in doing things like memory mapping files from ramfs. That
> could have an impact on library usage if there are issues. For example,
> does CoW work right for files memory mapped from ramfs? What would happen
> if a CoW was needed for a library mapped from ramfs when swap was full?
> Would it be a graceful process kill, or would the system seize up?
Since ramfs does not stop you from writing when the system is out of
memory it can create holes for DoS attacks. Don't let anybody but
root write to ramfs. Can we expect this to get fixed some day? Ramfs
was mostly meant to be an example of how to write filesystems. OTOH
I don't think you would be able to crash the system by executing
programs from ramfs, anyway it wouldn't be hard to test that in a
nonproduction environment.
>
> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
> | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
> -----------------------------------------------------------------
--
Kasper Dupont
------------------------------
** 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
******************************
