Linux-Development-Sys Digest #655, Volume #8     Fri, 20 Apr 01 00:13:19 EDT

Contents:
  Re: Is linux kernel preemptive?? (Moritz Franosch)
  Re: PCI card setup question (Grant Edwards)
  Re: Is linux kernel preemptive?? (=?iso-8859-1?Q?Andr=E9?= David)
  Re: a newbie in linux device driver writing. (philip)
  Re: IO system throughput ([EMAIL PROTECTED])
  Re: Is linux kernel preemptive?? (Joe Pfeiffer)
  Re: PCI card setup question ("Eric F. Richards")
  IBM JFS compilation  (Lan Huang)
  Re: ide vs. scsi why so much slower (bill davidsen)
  Re: ide_cs or ide-cs or what? (bill davidsen)
  Re: PCI card setup question (Pete Zaitcev)
  Re: A Linux emulator for Linux, does this exist? (Jonadab the Unsightly One)
  Re: A Linux emulator for Linux, does this exist? (Grant Edwards)

----------------------------------------------------------------------------

From: Moritz Franosch <[EMAIL PROTECTED]>
Subject: Re: Is linux kernel preemptive??
Date: 19 Apr 2001 19:16:09 +0200



Joe Pfeiffer <[EMAIL PROTECTED]> writes:

> > Well, I'm not an expert on Linux kernel code, but...
> > the original post didn't qualify to what degree 'preemptive' meant, and I can
> > guarantee that the kernel is to some degree preemptive. It certainly isn't a
> > non-preemptive kernel <g>.
> 
> By the definition I'm familiar with -- that user programs get
> preempted by the kernel, and don't need to explicitly relinquish
> control either explicitly or by requesting services -- it is fully
> preemptive.

What you mean is that the scheduler is preemptive. I thought the
kernel being preemptive means that the kernel gets preemped by user
programs (or by itself).

There is a patch for making the kernel "preemtible"
http://kt.zork.net/kernel-traffic/kt20010330_113.html#5
so I thought it is not preemtive (preemtible?, is there a difference?) 
now.

Moritz

------------------------------

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: PCI card setup question
Date: Thu, 19 Apr 2001 17:26:12 GMT

In article <8zED6.928$[EMAIL PROTECTED]>, Eric F. Richards wrote:

>So:  Do I fill them?  Does the kernel fill them?  If the latter,
>do I make a call to do so or is it done automagically for me?
>The old O'reilly book is too dated on this to be much help, and
>I can't wait for the next edition.

The kernel fills them in.  You can change them if you want, but
you probably don't need to.

Your best guide is to look at the sources for a working driver.
Pick one for a board similar to what you're using.  There are
various functions you call to find the slot for a board.  Look
int module init functions for calls that start with pcibios_.

For example:

 pcibios_present()
 pcibios_find_device()
 pcibios_read_config_word()
 pcibios_read_config_dword()
 pcibios_strerror()


>
>The kernel I'm using is 2.2.14-5.0 from Red Hat.
>
>Thanks in advance for any help!
>
>Eric
>
>-- 
>Eric F. Richards
>[EMAIL PROTECTED]
>"The weird part is that I can feel productive even when I'm doomed."
> - Dilbert


-- 
Grant Edwards                   grante             Yow!  I'm having an
                                  at               EMOTIONAL OUTBURST!! But,
                               visi.com            uh, WHY is there a WAFFLE
                                                   in my PAJAMA POCKET??

------------------------------

From: =?iso-8859-1?Q?Andr=E9?= David <[EMAIL PROTECTED]>
Subject: Re: Is linux kernel preemptive??
Date: Thu, 19 Apr 2001 19:31:39 +0200

This is a multi-part message in MIME format.
==============428B25CEDB01C58483F2A4E3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> so I thought it is not preemtive (preemtible?, is there a difference?)
> now.

Noun: Preemptive
Adverb, Adjective: Preemptible

At least for a portuguese guy like me it looks fine ;)

-- 

 "Share the code. If you hide it ain't good."
                                                Popular knowledge
==============428B25CEDB01C58483F2A4E3
Content-Type: text/x-vcard; charset=us-ascii;
 name="Andre.David.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for André David
Content-Disposition: attachment;
 filename="Andre.David.vcf"

begin:vcard 
n:David;André
tel;work:+41792013849
x-mozilla-html:FALSE
org:CERN - Centre Europeen de Recherche Nucleaire;Experimental Physics Division - NA60 
Experiment
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
note:Geneva, Switzerland
x-mozilla-cpt:;-11552
fn:André David
end:vcard

==============428B25CEDB01C58483F2A4E3==


------------------------------

From: philip <[EMAIL PROTECTED]>
Crossposted-To: fa.linux.kernel
Subject: Re: a newbie in linux device driver writing.
Date: Thu, 19 Apr 2001 17:58:41 GMT

Actually I have the book "linux device driver" written by alessandro rubini in my
hand for a quite while.
But that book need sequentially reading and not really comprehensive and handy
like a real reference gudie for kernel API.
  At this moment when I found some function which I don't know always just go to
source code and try to figure it out. it is not the best way but is the only way
I am choosing now. But even doing so still have some difficulty to understand
something like "callout function" at serial.c for linux serial port driver.
philip


[EMAIL PROTECTED] wrote:

> In article <eo%C6.2354$[EMAIL PROTECTED]>,
>  <[EMAIL PROTECTED]> wrote:
>
> >In comp.os.linux.development.system alan <[EMAIL PROTECTED]> wrote:
> >: true (and it's still a good book), that's why there's going to be a second
> >: edition...you can also get beta's of the new example source (which does
> >: support 2.4) for the second edition from
>
> >I've seen this mentioned a lot ... do you know the ETA on the 2nd edition?
>
> I haven't heard but many of the changes for 2.2 and 2.4 are documented
> here:
>
>    http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html
>    http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.4.html
>
> --
> http://www.spinics.net/linux


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: IO system throughput
Date: Thu, 19 Apr 2001 18:43:11 GMT

Greg Copeland <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
> [snip]
> > 
> > The issues with FibreChannel are pretty clear:
> > 
> > a) It's expensive hardware, so there aren't vast numbers of Linux
> >    users toying with it
> > 
> > b) Solaris seems to be the platform of choise for SAN
> > 
> > Put those together and you get the point that most of the effort goes
> > into Solaris drivers, what with vendor support and such, whilst Linux
> > gets support from people that have hardware and want to use it with
> > Linux.
> > 
> > Now, if we're talking about a $50 IDE controller, a $250 SCSI
> > controller, or a $200 motherboard, there's certainly going to be lots
> > of people that can easily afford to pick up hardware on the basis that
> > it _should_, _eventually_, be supported.  Put together 20 people that
> > do that, and work on drivers, and decent support can come quickly.
> > Even if it doesn't, it's not a _real_ big deal to write off $50 worth
> > of hardware.
> > 
> > In contrast, I'm not going to be buying an $80K SAN device on the
> > basis that it _might_ _eventually_ be supported.

> Thanks for the summary.  You make valid points.  In short, I don't
> think I'll be trying a fiber implementation for a while.  Let's face
> it, until you start to see a small segment of Linux "desktop" users
> with it, or even a small slice of the server pie, I don't think
> you're going to see any real support with fiber and Linux.

Desktop users are, in this context, _extremely_ irrelevant.  NOBODY is
going to be hooking an $80K SAN to their desktop.  Desktop's
irrelevant to the issue.

> It's worth pointing out that several other articles show that NT has
> a significant advantage when it comes to extremely heavy I/O because
> it supports an asynchronous I/O model.  Linux needs this very bad.
> It was one thing for Linux to shrug his shoulders when async I/O
> didn't make much sense for the low-end servers, however, Linux is
> trying to get into the enterprise which pretty much demands
> asynchronous I/O.  Let's face it, databases and build-your-own SANs
> and NASs pretty much require this type of heavy duty support.  If
> you read some of Oracle's papers, you'll find that they slam Linux
> from time to time for not supporting it too.

> As far as I can tell, with plenty of journaling file-systems coming
> the way of Linux, SMP and scheduler issues mostly addressed, and >2G
> files, the only thing that Linux needs to proper fiber support and
> asynchronous I/O support.  As much as I hate NT (I've used it tons,
> so I'm allowed to say that), MS did right by building in
> asynchronous I/O in almost all facets of NT's kernel and API.

Could you elaborate a little on what is meant by asynchronous I/O?

I can think of a number of models for it; most seem to require a
combination of kernel and user space support, and I can see the
"crossing of boundary" being a reason for Linus to be reluctant to
introduce it.

Is there a POSIX document on it to consult?
-- 
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://vip.hyperusa.com/~cbbrowne/resume.html
"I think it would be totally inappropriate for me to even contemplate
what I am thinking about."  -- Don Mazankowski

------------------------------

From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: Is linux kernel preemptive??
Date: 19 Apr 2001 12:43:50 -0600

Greg Copeland <[EMAIL PROTECTED]> writes:

> Prior to 2.4, Linux had lots of system calls that were not preemptive (coarse
> grain locks; networking was one such beast).  With 2.4, Linux got lots of fine
> grained locks which allows the kernel to be fully preemptive.  If I recall,
> there are still a couple of exceptions to the rule, however, most people now
> consider Linux to be a "fully" preemptive kernel.

This is why I was careful to put the definition I'm familiar with in
my answer -- you appear to be using a definition of a preemptive OS
that corresponds to the definition I'm familiar with for a preemptible
OS (which, thinking back to the original post, may well be what he had
in mind).

> Joe Pfeiffer <[EMAIL PROTECTED]> writes:
> [snip]
> > By the definition I'm familiar with -- that user programs get
> > preempted by the kernel, and don't need to explicitly relinquish
> > control either explicitly or by requesting services -- it is fully
> > preemptive.
> > 
> > Being able to do realtime stuff, with guaranteed maximum latencies and
> > the like, requires more than just being preemptive.

-- 
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
SWNMRSEF:  http://www.nmsu.edu/~scifair

------------------------------

From: "Eric F. Richards" <[EMAIL PROTECTED]>
Subject: Re: PCI card setup question
Date: Thu, 19 Apr 2001 20:30:02 GMT

Grant Edwards <[EMAIL PROTECTED]> wrote:
> In article <8zED6.928$[EMAIL PROTECTED]>, Eric F. Richards wrote:

>>So:  Do I fill them?  Does the kernel fill them?  If the latter,
>>do I make a call to do so or is it done automagically for me?
>>The old O'reilly book is too dated on this to be much help, and
>>I can't wait for the next edition.

> The kernel fills them in.  You can change them if you want, but
> you probably don't need to.

> Your best guide is to look at the sources for a working driver.
> Pick one for a board similar to what you're using.  There are
> various functions you call to find the slot for a board.  Look
> int module init functions for calls that start with pcibios_.

> For example:

>  pcibios_present()
>  pcibios_find_device()
>  pcibios_read_config_word()
>  pcibios_read_config_dword()
>  pcibios_strerror()

Actually I am using all of those except the _read_config_ (and
the corresponding _write_config_ calls.

One of the problems I am finding is that existing drivers are
written to be backward compatible with earlier versions of the
kernel and 2.2.x is the earliest I need to support, which is why
I ask the question.  The normal approach would be to build my
own structs and fill them independently of the kernel and rely
on them but I didn't want to reinvent the wheel.

Eric

>>
>>The kernel I'm using is 2.2.14-5.0 from Red Hat.
>>
>>Thanks in advance for any help!
>>
>>Eric
>>

-- 
Eric F. Richards
[EMAIL PROTECTED]
"The weird part is that I can feel productive even when I'm doomed."
 - Dilbert

------------------------------

From: [EMAIL PROTECTED] (Lan Huang)
Subject: IBM JFS compilation 
Date: 19 Apr 2001 17:49:23 -0500

Hi, 

Anyone has any experience in IBM JFS?
Sorry in advance if my question may sound stupid. But here is my question:
I have problem running a kernel with JFS compiled in my linux box: redhat
7.0, kernel 2.2.16, PII 300, 128M memory.

I used the jfs-0.2.2.patch, and compiled successfully in 
a linux-2.2.19 src tree. 

Then I copied the bzImage to root directory, run lilo,
and reboot using new kernel.
The kernel cannot boot successfully. Error happens after "JFS development
version" mesg, and VFS is mounted read-only. Error mesg is "FATAL cannot
determine library version" and machines hangs there.

Maybe I missed something somewhere? Thank you for your help.

Mel.


[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: ide vs. scsi why so much slower
Date: 19 Apr 2001 23:09:55 GMT

In article <[EMAIL PROTECTED]>,
Eric Taylor  <[EMAIL PROTECTED]> wrote:

| So, I get this:
| 
| scsi   33    meg/second
| ide    4.5   meg/second  - no dma
| ide   12.7   meg/second  - with dma

| Can someone explain why such a difference. The
| ide drives are ata 100 7200 rpm. Not sure about
| the scsi device.

DMA is nice, did you put the drive in ATA/100 mode? You should download
the current hdparm (4.1 I believe) and set the options:
  -d1 -u1 -m8 -c3 -W1 -A1
which I got from the IDE God, Mark Lord, and see if that make a small
improvement of about 500%.

-- 
  bill davidsen <[EMAIL PROTECTED]>  CTO, TMR Associates, Inc
"I am lost. I am out looking for myself. If I should come back before I
return, please ask me to wait."  -seen in a doctor's office

------------------------------

From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: ide_cs or ide-cs or what?
Date: 19 Apr 2001 23:16:53 GMT

In article <774C6.7820$[EMAIL PROTECTED]>,
Harmon Seaver  <[EMAIL PROTECTED]> wrote:
|   I can't seem to get my pcmcia reader to work with flash cards under
| 2.4.3 -- it can't find the ide_cs.o module, although that should be compiled
| as a module. I see elsewhere mention of a problem with the /etc/pcmcia/config
| having ide_cs.o (like it always was) and the new kernels do it as 
| ide-cs.o -- so anyway I tried it both ways but no go. What is going
| on with this? 

First, let me say that my opinion of the implementation in the kernel
couldn't go in a technical group. One problem after the other.

The good news is that the 2.4.3-ac9 kernel, with the latest pcmcia
3.1.25 with all the pcmcia OUT of the kernel and in the separate code,
not only works, but is the first kernel in 2.4 to work *right* for me. I
have a server, with SMP, and pcmcia plugged into the bus with an
adaptor, and with this kernel I not only can use my flash cards, but if
I do an "eject" on the card it unmounts the filesystem, and when I pull
out the card the system doesn't crash.

It will find modem and NIC cards, I haven't tried to use them, as this
system doesn't need them. Does beat USB for getting data out of my
cameras, though.

As always YMMV.

-- 
  bill davidsen <[EMAIL PROTECTED]>  CTO, TMR Associates, Inc
At LinuxExpo Sun was showing Linux applications running on Solaris.
They don't get it, the arrow points the other way. There's a reason why
there's no SolarisExpo, Solaris is a tool; Linux is a philosophy, a
religion, a way of life, and only incidentally an operating system.

------------------------------

From: Pete Zaitcev <[EMAIL PROTECTED]>
Subject: Re: PCI card setup question
Date: Thu, 19 Apr 2001 17:18:26 -0700

> So:  Do I fill them?  Does the kernel fill them?  If the latter,
> do I make a call to do so or is it done automagically for me?

> Eric F. Richards

Just use values that system provides (filled by the bus scan
on boot or hotplug). Reading them from PCI base registers
works on some platforms only. Look at Documentation/IO-mapping.txt.

-- Pete

------------------------------

From: [EMAIL PROTECTED] (Jonadab the Unsightly One)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Fri, 20 Apr 2001 00:49:16 GMT

"Peet Grobler" <[EMAIL PROTECTED]> wrote:

> <SNIP>
> >happen. According to folklore, you can pretty much replace an
> >entire 390 one piece at a time without ever rebooting -- I
> >imagine that's a bit exagerated.
> 
> Yes, I believe you can. If everything in the system is 
> hot-swappable, why not?

There's got to be a bus that connects everything.  
Even if you can swap out one-by-one all the hard 
drives, all the RAM, all the I/O stuff, individual
processors, and so on, at some point there's going
to be a piece that ties it all together, the bus
if you will.  Unless it's highly modular, you 
won't be able to swap out that part with the 
system running.  

Also the power supply could be a problem, unless
it has multiple redundant power supplies.  

- jonadab

------------------------------

From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Fri, 20 Apr 2001 04:08:35 GMT

In article <[EMAIL PROTECTED]>, Jonadab the Unsightly One wrote:

>>>happen. According to folklore, you can pretty much replace an entire 390 one
>>>piece at a time without ever rebooting -- I imagine that's a bit exagerated.
>> 
>> Yes, I believe you can. If everything in the system is hot-swappable, why
>> not?
>
>There's got to be a bus that connects everything.

Rudundant interconnects are possible.  Don't know if the 390 has them.

>Even if you can swap out one-by-one all the hard drives, all the RAM, all
>the I/O stuff, individual processors, and so on, at some point there's going
>to be a piece that ties it all together, the bus if you will.  Unless it's
>highly modular, you won't be able to swap out that part with the system
>running.

There probably are single points of failure in some inter-connect hardware.

>Also the power supply could be a problem, unless
>it has multiple redundant power supplies.  

The power-supply is one of the simplest for which to provide redundancy. Far
easier than disks, memory or CPUs.  A couple current steering diodes, and
Bob's your uncle.

-- 
Grant Edwards                   grante             Yow!  ... My pants just
                                  at               went on a wild rampage
                               visi.com            through a Long Island
                                                   Bowling Alley!!

------------------------------


** 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
******************************

Reply via email to