Linux-Development-Sys Digest #711, Volume #7 Tue, 28 Mar 00 08:13:10 EST
Contents:
BIOS support (Sebastien Dessimoz)
Re: BIOS support (Robert Redelmeier)
Re: Advice on PowerPC MPC823 Dev. Tools? (Kenneth Porter)
Re: Advice on PowerPC MPC823 Dev. Tools? (Matt Porter)
resource quotas (Nick Piggin)
Mouse Driver Development (Curt)
Re: Absolute failure of Linux dead ahead? (Christopher Browne)
FHS linux: help clearify folders (Erika Pacholleck)
Re: implementing restartable system calls in a module (nilesh patel)
MIDL compiler ("Hubert")
Re: Advice on PowerPC MPC823 Dev. Tools? (Wolfgang Denk)
Re: Mouse Driver Development (Alan Donovan)
Re: implementing restartable system calls in a module (Alan Donovan)
Re: Changing kernel parameters ([EMAIL PROTECTED])
Re: date (Damon Register)
Upgrading to 2.2.14. Help? ([EMAIL PROTECTED])
usb-uhci interrupt rate (DaveyBT)
----------------------------------------------------------------------------
Date: Mon, 27 Mar 2000 16:05:02 -0800
From: Sebastien Dessimoz <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: BIOS support
Hi,
I'd like to know if Linux uses the BIOS (except loading the Linux kernel
image of course)?
Thanx
Sebastien
------------------------------
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: BIOS support
Date: Mon, 27 Mar 2000 20:18:19 -0800
Sebastien Dessimoz wrote:
> I'd like to know if Linux uses the BIOS (except loading the Linux kernel
> image of course)?
The canonical answer is no, Linux does not use the BIOS for anything
beyond loading the kernel image. BIOS is 16 bit real-mode code, and
Linux is 32 bit pmode. The segregs do not line up at all.
OTOH, something like DOSemu, WINE or the like _might_ try to use v86
mode, but I doubt it.
More to the point, many portables use BIOS for power managment, and this
works under Linux. I presume this is using SMM (System Management Mode)
running off BIOS code. Linux might use BIOS for APM, but again, I doubt
it. grep the source for ` int ` calls. AFAIK, ECC is also done thru
SMM into BIOS.
You might look into some of the embedded Linux work.
-- Robert
------------------------------
From: [EMAIL PROTECTED] (Kenneth Porter)
Crossposted-To: comp.arch.embedded,comp.sys.powerpc.tech
Subject: Re: Advice on PowerPC MPC823 Dev. Tools?
Date: Tue, 28 Mar 2000 02:23:01 GMT
[EMAIL PROTECTED] (Matt Porter) wrote in
<[EMAIL PROTECTED]>:
>On Fri, 24 Mar 2000 20:00:42 GMT, Casey Smith <[EMAIL PROTECTED]>
>wrote:
>> Hi there.... I'm building USB-MIDI device based around a MPC823.
>>Does anyone have any experience with the various development tools
>>available from Motorola and third party vendors?
>>Any recommendations are appreciated.
>
>I don't use anything but GNU tools for development. See
>http://www.mvista.com for prepackaged MPC8xx tools.
I checked out MontaVista's web site and see that Hard Hat Linux is
available for the MPC823FADS, but I couldn't figure out how one acquires
it. The product description suggests that the hardware partner provides it,
but I didn't see it at Mot's website in the FADS section.
------------------------------
From: [EMAIL PROTECTED] (Matt Porter)
Crossposted-To: comp.arch.embedded,comp.sys.powerpc.tech
Subject: Re: Advice on PowerPC MPC823 Dev. Tools?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 28 Mar 2000 04:38:04 GMT
On Tue, 28 Mar 2000 02:23:01 GMT, Kenneth Porter <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Matt Porter) wrote in
><[EMAIL PROTECTED]>:
>
>>On Fri, 24 Mar 2000 20:00:42 GMT, Casey Smith <[EMAIL PROTECTED]>
>>wrote:
>>> Hi there.... I'm building USB-MIDI device based around a MPC823.
>>>Does anyone have any experience with the various development tools
>>>available from Motorola and third party vendors?
>>>Any recommendations are appreciated.
>>
>>I don't use anything but GNU tools for development. See
>>http://www.mvista.com for prepackaged MPC8xx tools.
>
>I checked out MontaVista's web site and see that Hard Hat Linux is
>available for the MPC823FADS, but I couldn't figure out how one acquires
>it. The product description suggests that the hardware partner provides it,
>but I didn't see it at Mot's website in the FADS section.
MV probably ought to do a better job explaining how to get Hard Hat Linux
on the web site. In the meantime, send mail to the sales/info contacts
to get that information.
For the FADS case, note that Mot is notoriously slow at updating public web
information so the best way to find out about it is to contact MV.
--
Matt Porter
[EMAIL PROTECTED]
This is Linux Country. On a quiet night, you can hear Windows reboot.
------------------------------
Date: Tue, 28 Mar 2000 14:44:11 +1000
From: Nick Piggin <[EMAIL PROTECTED]>
Subject: resource quotas
I'm new (~1 year) to the linux system, however I have lately been
following some of the kernel development newsgroups with interest. Maybe
not kernel related, but is it possible to have a program/kernel option
to quota more resources (other than just disk space). ie. it would be
nice to have a quota on number of processes, cpu %, memory, device usage
- ie. network/disk (not storage, but mb/s). I am aware that some tools
will do similar jobs such as 'nice' and a good system admin can do these
things quite easily however it would be nice to have more quantitative
measures and limits for these resources.
I am not sure weather any features like this exist or not and if they
don't I understand it would probably be because of the prohibitive
performance impact they would incur and they may hardly be needed on
small systems, however they could ease the job of a admin for larger
systems.
Please feel free to put me on the right track if I'm way off, but it was
just a thought.
Thanks,
Nick.
------------------------------
From: Curt <[EMAIL PROTECTED]>
Subject: Mouse Driver Development
Date: Tue, 28 Mar 2000 05:48:47 GMT
I am interested in developing a driver for my Dexxa Scroll mouse. I'm
not really sure where to start. I'm a good C programmer, but
unfortunatly most of my programming experience is in winblows. If
somebody could lend a hand; tell me where some resources are.
Curt
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 28 Mar 2000 06:41:18 GMT
Centuries ago, Nostradamus foresaw a time when Joseph T. Adams would say:
>In comp.os.linux.advocacy Warren Young <[EMAIL PROTECTED]> wrote:
>
>: Face it, there's a prejudice in favor of C. It can't be considered
>: anything other than prejudice, because logical arguments in favor of
>: other languages fail regularly.
>
>This is not prejudice. I don't especially like C, and I wish there
>were something better that could replace it, but as yet nothing has
>proven to be even as good as C, much less better, for what C is mainly
>used for: development of compact and portable systems software.
>
>Anything that replaces C would have to be almost as fast, and would
>have to offer advantages that C doesn't. The only language AFAIK that
>meets both criteria is C++. C++ is being adopted only very slowly in
>the Linux world, for reasons I consider quite understandable.
>
>The main problem with C++ IMO is that pre-Standard C++ is not even
>close to being portable, and Standard C++ is very complex and
>therefore very difficult to implement correctly.
This isn't the *main* problem.
The *main* problem is that by adopting C++, you adopt the binary
representations of its object model. For which there are *no* standards
defined.
In order to link outside code to C++ code, you pretty much need to
define C bindings for all the bits you'd like to "publish" for public
use.
>For large, monolithic projects such as KDE and Mozilla, C++ is great,
>because it can work at high and low levels of abstraction
>simultaneously, and it is unique among widely-used languages in that
>regard.
>
>But for a system like Unix or Linux which is based on small, fast,
>robust components that are glued together by higher level scripting
>languages (most of which support OOP), C++ has relatively little to
>offer.
At least in theory, there should be no reason why you could not
construct small, fast robust components written in C++ that would
be linked together via shell scripts.
>As time goes on, C++ implementations will improve, and it is possible
>that the Standard will evolve to support subsets of the language that
>are smaller and easier to implement. (Embedded systems need a smaller
>C++ far more than Linux does.) I would assume that at that point, we
>will see more large pieces of open-source software switching to C++.
The problem that needs to be "solved" in order to increase the
adoption of C++ is that of library interoperability. The lack of
standardization, and the continuing evolution of implementations,
has prevented there being stable ways to combine libs from disparate
places without pretty much compiling it all yourself at one time.
Consider: Qt compiled using EGCS may not interoperate with Qt apps
compiled using GCC < 2.95 or with Qt components compiled with GCC version
>= 2.95.
And this sort of problem is likely to persist for some time to come,
and is really only resolved by some body coming up with a standard,
whether formal or informal.
--
"Oh, I've seen copies [of Linux Journal] around the terminal room at
The Labs." -- Dennis Ritchie
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
Date: Tue, 28 Mar 2000 09:01:11 +0200
From: Erika Pacholleck <[EMAIL PROTECTED]>
Subject: FHS linux: help clearify folders
Hi,
would anyone pls. help clearify the definition of some folders
which should be compliant to FHS (have been reading it but
can't find the answer). So would this be allowed:
ques 1: cron folders get an own dir
exampl 1: /etc/cron.daiyly <-- or --> /etc/cron.d/daily
ques 2: initscripts get an own dir
exampl 2: /etc/rc0.d <-- or --> /etc/rc.d/rc0.d
If there is any further link except the mere paper,
I would be pleased to hear about that.
Thanks in advance.
Erika
------------------------------
From: nilesh patel <[EMAIL PROTECTED]>
Subject: Re: implementing restartable system calls in a module
Date: Tue, 28 Mar 2000 13:08:15 +0530
Alan Donovan wrote:
It is the responsibility of the driver to undo the writes in case if any
signal occurs.
However it is not a big job to undo the writes , it involves only shifting
the buffer pointer for the kernel buffer where the bytes are written.
> I'm reading p112 of Rubini's Linux Device Drivers. It says that in a
> driver's write() method, if while the process is blocked in
> interruptible_sleep_on a wait queue, and a signal is received, that the
> driver should return -ERESTARTSYS to the layer above.
>
> My question is this: normally a driver returns the number of bytes
> written to the layer above. In the case where the call is interrupted by
> a signal, what happens to the value of the number of bytes written? The
> kernel may attempt to restart the system call with the same parameters,
> but if the interrupted call wrote some bytes, this will be disastrous.
>
> The manpage for write(2) says that EINTR implies that zero bytes were
> written, so that makes sense and seems safe. But how does the average
> driver know, when a process is woken by a signal, that zero bytes have
> been written? In my driver, I don't think it's possible for me to know
> how many bytes have been written within my write() method: what do I
> return?
>
> TIA
>
> alan
>
> --
> ------------------------------------------------------------------------
> Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
> Imerge Ltd. +44 1223 875265
------------------------------
From: "Hubert" <[EMAIL PROTECTED]>
Subject: MIDL compiler
Date: Tue, 28 Mar 2000 09:49:26 +0200
Hello,
I would like to port my windows application which uses RPC to SUSE.
Therefore I am looking for a MIDL compiler to generate the necessary stubs
from the IDL file.
Does anyone know where a can find a MIDL compiler for LINUX?
Thank you
Hubert
------------------------------
Crossposted-To: comp.arch.embedded,comp.sys.powerpc.tech
From: Wolfgang Denk <[EMAIL PROTECTED]>
Subject: Re: Advice on PowerPC MPC823 Dev. Tools?
Date: Tue, 28 Mar 2000 07:10:48 GMT
[EMAIL PROTECTED] (Kenneth Porter) writes:
>>> Hi there.... I'm building USB-MIDI device based around a MPC823.
...
>I checked out MontaVista's web site and see that Hard Hat Linux is
>available for the MPC823FADS, but I couldn't figure out how one acquires
>it. The product description suggests that the hardware partner provides it,
>but I didn't see it at Mot's website in the FADS section.
There are other options beside the FADS...
I've been using the TQM mini modules (MPC8xx with up to 64 MB DRAM, 8
MB FLASH, TP Ethernet, 2x RS232, parallel port, USB, CAN bus, ... on
54x81 mm� - that's less than half the size of a credit card).
See http://www.tqc.de/HTM_Files/TQM8xx_Serie.htm for initial informa-
tion about the hardware, and http://www.denx.de/solutions-en.html for
a list of software options available for those boards.
And feel free to ask me.
Wolfgang
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: -88 Home: -86 Email: [EMAIL PROTECTED]
Only in our dreams we are free. The rest of the time we neeed wages.
- Terry Pratchett, _Wyrd Sisters_
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: Mouse Driver Development
Date: Tue, 28 Mar 2000 11:58:44 +0100
Curt wrote:
>
> I am interested in developing a driver for my Dexxa Scroll mouse. I'm
> not really sure where to start. I'm a good C programmer, but
> unfortunatly most of my programming experience is in winblows. If
> somebody could lend a hand; tell me where some resources are.
>
Read the (long) article by Alan Cox which Nilesh Patel posted a couple
of days ago in response to a post of mine on a different subject. The
subject was "interrupts and atomicity in drivers".
alan
--
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
------------------------------
From: Alan Donovan <[EMAIL PROTECTED]>
Subject: Re: implementing restartable system calls in a module
Date: Tue, 28 Mar 2000 12:57:26 +0100
nilesh patel wrote:
> It is the responsibility of the driver to undo the writes in case if any
> signal occurs.
> However it is not a big job to undo the writes , it involves only shifting
> the buffer pointer for the kernel buffer where the bytes are written.
In my driver, the "write" method (when blocking) fills the DMA buffer
and then, if there is more data still to write, does a sleep on a wait
queue. When the DMA is complete, the interrupt BH wakes the process,
which fills the DMA buffer again with the next chunk, and so on, until
the whole block passed to write(2) in user mode has been put in the DMA
buffer.
If, when the sleep is woken, the process has been signalled, then to
implement restartable semantics you say I must be able to undo the
writes: however the data might already have been DMAd and consumed by
the hardware.
I've included some code below: am I doing it wrong?
alan
BTW: another question: if during a cli..sti lock, you execute code that
faults while probing user space, does the kernel's exception handler
reenable interrupts, or simply return the top-level method with EFAULT
leaving them disabled? Would this be bad?
========================================================================
Alan Donovan [EMAIL PROTECTED] http://www.imerge.co.uk
Imerge Ltd. +44 1223 875265
Note: add_to_dma_buf adds adds up to "count" bytes from "buf" to the DMA
buffer. It may fault.
Note: "chan" points to data that is modified by the interrupt handler's
BH, hence locks.
ssize_t linn_write(struct file *filp,
const char *buf, size_t count, loff_t *ppos)
{
Linn_Channel *chan = filp->private_data;
ssize_t bytes_written = 0;
if(filp->f_flags & O_NONBLOCK) /* nonblocking */
{
/* add up to "count" bytes to the DMA buffer */
cli();
bytes_written = add_to_dma_buf(chan, buf, count);
sti();
/* note -- this is safe when add_to_dma_buf faults */
/* there is no space left in the DMA buffer: try again later */
if(bytes_written == 0)
return -EWOULDBLOCK;
}
else /* blocking */
{
while(count > 0)
{
/* add up to "count" bytes to the DMA buffer */
ssize_t chunk, bytes;
bool _continue;
cli(); /* lock access through "chan" */
chunk = add_to_dma_buf(chan, buf, count);
bytes = chan->bytes;
sti();
if(chunk == -EFAULT)
return -EFAULT;
bytes_written += chunk;
count -= chunk;
/* once the last of the user data is in the DMA buffer, break */
if(count == 0)
break;
/* DMA buffer is full but write is not complete: must
* block until DMA buffer is emptied. */
do
{
/* wait for the magic to happen */
interruptible_sleep_on(&chan->wq_write);
/* if we are signalled, just return our current progress */
if(signal_pending(current))
{
/* NOTE: not all of "bytes_written" may have been
* written to the device yet, but the point is,
* that's how many are in the DMA buffer and
* therefore will get written.
*/
return bytes_written;
}
/* This check is to ensure that the bytes have been
* written and that we didn't wake up for some
* spurious reason (e.g. blocked signal) */
cli();
_continue = (chan->bytes != bytes);
sti();
} while(_continue);
}
}
return bytes_written;
}
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Changing kernel parameters
Date: 28 Mar 2000 12:37:30 GMT
What are you trying to accomplish? There are a number of different
places where you change things in the kernel, depending upon what
you're attempting to do.
--J
[EMAIL PROTECTED] wrote:
: New to Linux. How do I change the kernel parameters? Thanks
: --
: Posted via CNET Help.com
: http://www.help.com/
------------------------------
From: Damon Register <[EMAIL PROTECTED]>
Subject: Re: date
Date: Tue, 28 Mar 2000 07:50:30 -0500
On Mon, 27 Mar 2000 17:58:47 +0200, "Lothar Dickhoff"
<[EMAIL PROTECTED]> wrote:
>
>Try "man hwclock" to see the options.
>
Thanks for the information. This benefited me too.
Damon Register
------------------------------
From: [EMAIL PROTECTED]
Subject: Upgrading to 2.2.14. Help?
Date: 28 Mar 2000 12:57:55 GMT
Hey all.
I'm working on upgrading my Gateway 2K Solo 2300 laptop from 2.0.34 to
2.2.14. I'm going through the Changes file and a lot has had to be upgraded.
Messes so far:
1) Installation of binutils 2.9.5.0.31 failed during 'make install' because
make doesn't understand how to make target '../libiberty/libiberty.a', which
is needed by 'size'.
2) The 'configure' script that comes with libc6 fails, more or less, because I
get the following strange things:
configure: warning:
*** (g)msgfmt is too old or wrong version (need GNU gettext 0.10 or better).
and the following near the bottom:
*** You should not compile the GNU libc without the 'linuxthreads' and
*** 'crypt' add-on. Not using them risks to be incompatible wit the
*** libraries of other systems. Consier getting the add-ons and restarting
*** the configuration.
3) I went to install util-linux-2.10h, but it has many, many nasty warnings
about seriously messing up my system, and it mentions that it doesn't support
shadowed passwords unlesss I'm using PAM.
So. <sigh> Here are he questions:
1) Where can I get a copy of binutils that will install correctly, and will
the failed install screw things up?
2) Where can I get msgfmt (where's the GNU gettext package), and do I care
about the other errors?
3) How can I tell what type of shadowed password package I'm running, and
is util-linux-2.10h relatively safe to install on a Slackware machine?
Thanks in advance. E-mail is appreciated, but I'll be checking the group.
Later...
--J
------------------------------
From: DaveyBT <[EMAIL PROTECTED]>
Subject: usb-uhci interrupt rate
Date: Tue, 28 Mar 2000 14:04:23 +0100
I'm running 2.3.99-pre3 on a PPro system, Intel PIIX3 chipsets and I am
seeing around 1000 interrupts per second on the usb-uhci interrupt from
/proc/interrupts.
Anyone out there know if this is a known problem (or is not an issue)?
thanks,
DaveT
------------------------------
** 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
******************************
