Linux-Development-Sys Digest #631, Volume #7     Sun, 27 Feb 00 15:13:25 EST

Contents:
  Re: the init of wait queue? ([EMAIL PROTECTED])
  Re: Detecting installed Harddrives (Lee Webb)
  getting a linksys ether fast card to work in red hat 6.1 ("Lee Klasing")
  Re: Detecting installed Harddrives (Eduard Bloch)
  Re: Linux or Windows (GriffD2000)
  Re: Linux or Windows (Doug Schiffer)
  Re: complex math in a device driver (Johan Kullstam)
  Urgent!:Size of message queues on sys5 (shankar kalyanaraman)
  synchronization  with mmap (liran)
  lowlevel and highlevel hardware access (BerryBear)
  Re: complex math in a device driver (Oliver Bandel)

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

From: [EMAIL PROTECTED]
Subject: Re: the init of wait queue?
Date: Sun, 27 Feb 2000 08:58:47 GMT

On Sun, 27 Feb 2000 05:51:36 GMT Kaz Kylheku <[EMAIL PROTECTED]> wrote:

| Either way, this is extremely skanky C coding. What I do not understand is why
| the wait queue is not defined so that the next pointer is the first member.
| Then this trick would be implemented much more neatly without the arithmetic! 
|
| I suppose that Linus wanted the task pointer to be the first member for some
| optimization reason, and the trick works on all architectures.

I've often done the following.  The anchor is NULL if the queue is empty.
The anchor points to the LAST node of the queue.  The last node points to
the first node.  I can add a new node to the back or front in O(1) time.
I can delete the FIRST node in O(1) time (but deleting the last node would
be O(N) because I would have to run around the queue to find the next to
last node, but a queue doesn't generally need to delete from the back end).
If I have to be able to delete on either end I do a doubly-linked list.
Anything more complex and I do a binary tree or a hash.

-- 
| Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| [EMAIL PROTECTED] | really matter:     | Boycott Amazon.Com (AMZN)     |
| Dallas - Texas - USA | linuxhomepage.com  | Shop http://bn.com/ instead   |

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

From: Lee Webb <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Detecting installed Harddrives
Date: Sun, 27 Feb 2000 11:24:53 +0000

Off the top of my head, you could look in /etc/mtab to see which partitions are
currently mounted, or there should be something in the /proc fs. 
Sorry I can't be more precise, but I'm stuck in Windows as the moment (internet
refuses to work in Linux at the moment).

Lee.

Benjamin Lippelt wrote:
> 
> Hi,
> 
> how can I find out which harddrives are installed (e.g. /dev/hdc1) on a
> Computer ? Is there a configuration-file or a kernel-function ?
> 
> Thx Benni

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

From: "Lee Klasing" <[EMAIL PROTECTED]>
Subject: getting a linksys ether fast card to work in red hat 6.1
Date: Sun, 27 Feb 2000 07:04:03 -0600

I have a question i have a network card that wasnt detected in install and
im a newbie.  It is used for a cable modem and i dont know how to setup the
card?
any ideas?





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

From: [EMAIL PROTECTED] (Eduard Bloch)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Detecting installed Harddrives
Date: 27 Feb 2000 11:15:10 GMT
Reply-To: [EMAIL PROTECTED]

Am Sat, 26 Feb 2000 23:44:29 +0100 schrieb/wrote/a �crit 
Benjamin Lippelt <[EMAIL PROTECTED]> in comp.os.linux.development.apps:

>how can I find out which harddrives are installed (e.g. /dev/hdc1) on a
>Computer ? Is there a configuration-file or a kernel-function ?

Hm, just read the content of files in /proc/ide or /proc/scsi.
Altirnatively, you could call "fdisk -l /dev/whatever" to look for
partitions.

Greetings,
Eduard.

-- 
=====================================================================
Eduard Bloch <[EMAIL PROTECTED]>; HP: http://eduard.bloch.com/edecosi

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

From: [EMAIL PROTECTED] (GriffD2000)
Subject: Re: Linux or Windows
Date: 27 Feb 2000 15:54:00 GMT

>>> I am debating wheather to run Linux on my computer or to stick with
>  >> windows.  I know very little about linux and want to know which is
>  >> best.  I want to be able to run it on the same computer as
>  >> windows. Help please.
>
>  rm> Put two hard disk IDE in your computer. One for Windows, one for
>  rm> Linux. It is a fine solution.
>
>You don't even need two hard disks.  You can put a very respectable
>Linux installation in 2G (I've loaded usable ones in 750M).
>
>Most systems these days come with HDs of 6+G, so there's plenty of room
>for both OS's on one system, even if Windows is, uh, a bit "fatter" than
>Linux ;).
>
>I dual-boot with a menu at boot time that lets me choose which I want,
>and it works great.

I agree.  I have an old 486 with a 1.7 GB hard drive. i dedicate about 600 MB
to linux and use a multiboot system (not LILO, but LILO will do the job) and it
works great.

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

From: Doug Schiffer <[EMAIL PROTECTED]>
Crossposted-To: 3dfx.linux.apps.other
Subject: Re: Linux or Windows
Date: Sun, 27 Feb 2000 12:56:52 -0500



"Paul D. Smith" wrote:

> %% R.M <[EMAIL PROTECTED]> writes:
>
>   >> I am debating wheather to run Linux on my computer or to stick with
>   >> windows.  I know very little about linux and want to know which is
>   >> best.  I want to be able to run it on the same computer as
>   >> windows. Help please.
>
>   rm> Put two hard disk IDE in your computer. One for Windows, one for
>   rm> Linux. It is a fine solution.
>
> You don't even need two hard disks.  You can put a very respectable
> Linux installation in 2G (I've loaded usable ones in 750M).
>
> Most systems these days come with HDs of 6+G, so there's plenty of room
> for both OS's on one system, even if Windows is, uh, a bit "fatter" than
> Linux ;).

The proper technical term is "morbidly obese"....  :-)


> I dual-boot with a menu at boot time that lets me choose which I want,
> and it works great.

Same here.   Linux is gradually getting booted more and more often as I shift
applications over to it.  Someday, I hope to only have to boot Windows on rare
occasions...

--
It is a poor workman indeed who blames his tools.  But it takes a completely
wretched workman to blame his creations.  Such a workman is not only bereft of
talent.  They are also devoid of understanding, responsibility and even
intelligence.



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

Subject: Re: complex math in a device driver
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: Sun, 27 Feb 2000 18:05:32 GMT

Bryan Hackney <[EMAIL PROTECTED]> writes:

> Andreas Jaeger wrote:
> > 
> [...]
> > 
> > You can't use any floating point in the kernel at all.  No chance
> > AFAIK.  You have to solve this differently.  Are you sure that this
> > cannot done in userspace?
> > 
> > Andreas
> > --
> [...]
> 
> There has to be a way.

yes.  do fixed point math with integers.

of course, you'll need to take care of rounding and shifting the
results.

if worst comes to worst you can roll your own minimal floating point
library out of integers.  put mantissa in one integer variable, put
exponent in the other.

> think the problem is that the kernel does not save FP state - you
> would have to figure out how to push and pop FP state, and make
> absolutely sure your code is atomic.

correct.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!

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

From: shankar kalyanaraman <[EMAIL PROTECTED]>
Subject: Urgent!:Size of message queues on sys5
Date: Sun, 27 Feb 2000 15:16:02 +0530




Hi

        I need to know the maximum size of the message queue allowable
 on Sys5.I have 2.2.12 at home.We need to implement a data link layer
 that provides basic functions like sending and receiving of packets to 
 applications like FTP.We are required to implement this using interprocess
 communications without forking for various applications (or clients)

        I'd appreciate advice on what is the best possible IPC method to
 use for this purpose.I am given to understand that message queues are small
 and thus bad for this purpose.Thanks in advance.

bye
shankar

(at)='@'
(dot)='.'
shankar_k(at)vsnl(dot)com


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

From: liran <[EMAIL PROTECTED]>
Subject: synchronization  with mmap
Date: Sun, 27 Feb 2000 11:55:23 -0800

Hi,
I did some experience by implementing the mmap metho in
device drivers and I found problems in synchronization
between memory anf f.s .where can I read about it?
where is the code that responsible for that?
thanks liran.


* Sent from AltaVista http://www.altavista.com Where you can also find related Web 
Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful

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

From: BerryBear <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.help
Subject: lowlevel and highlevel hardware access
Date: Sun, 27 Feb 2000 20:32:30 +0100

I'd like to understand hardware access in Linux. How does it work?
What are the different possibilities of accessing hardware like
printers, scanner, gamepads, soundcards, keyboard, graphic cards and
mice.
Please tell me where I can find information and (good) libraries related
to that problem. I've spent a lot of money searching for information in
the internet :-(

berrybear


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

From: Oliver Bandel <[EMAIL PROTECTED]>
Subject: Re: complex math in a device driver
Date: 27 Feb 2000 02:03:27 +0100


Grant Edwards <[EMAIL PROTECTED]> wrote:
> In article <89782j$[EMAIL PROTECTED]>, Oliver Bandel wrote:
>>
>>Dan Miller <[EMAIL PROTECTED]> wrote:
>>> I need to access some math library function in my device driver.  I believe
>>> I've read here that one cannot do that, and I don't actually see a way to do
>>[...]
>>
>>Why should you use math in a device driver?

> To provide a layer of abstraction.

Provide it, but not in in the device driver.


> For example, if I have a set of
> analog inputs, and I make an IOCTL call to read the voltages, it's
> awfully nice to get answers in volts.  That way the driver has to keep
> track of the peculiarities of the hardware rather than the user
> software.

You have to provide a device driver and a small library.
The device driver does only some "stupid" things like
a device driver only does...
Your small library then do the math stuff.
The advantage of this: You can change your ahrdware without
changing your driver; you only use a newer lib for your
new hardware.
Tha adavantage of this: 
 * less sources to the kernel => lower
   bug-rate on the driver's software => stability of the syetem.
 * you only have to develop a new version of the library for the
   hardware; the driver in the kernel is the same. And that means
   a stable kernel.
   If errors occur, you maybe get a coredump or an wrong voltage,
   but the system don't care and runs.... and runs.....

> Much like SCSI hides the whole cylinders, heads, sectors
> stuff from the user program, it would be nice if device drivers could
> hide the ugly details of A/D and D/A hardware from the user.

If the SCSI driver hide the whole filesytem to the user,
thats - maybe - easyer for the user, but then you go the way,
where every apllication will be implemetde in the kernel
as a driver.
Than you only have kernelapplications and that's not,
what a real unix-like system is. 

The big advantage of doing rather less in one level, but
develop much of these levels is the right way.

As you know (do you?), the OSI-model has more  levels/layers
as the real implementaztions.

What you know want to do is, to reduce the number of layers
again! That's the wrong way!

I think you want to use DOS!



Provide a "stupid" device driver and a device-independent
library. So you canb use ONE device driver for all versions
of your hardware and only change the user-space-library.


>>Don't mix the different levels of software!

> As things currently exist, you read an analog input value and you get
> an integer.

Well... that's, what an A/D is doing.

It only gives you an integer! 

What's the difference between a continous and a discrete
Fourier transformation?
The continoushas an physical unit, the discrets's unit
is "one".

But even if that difference is not here: A device driver
has nothing to do with the real world. It only drives the
device. And that's why it's named a "device driver"!


The kernel/the OS does the low-level-things,
the libraroes does the not-so-low-level-things.

Well, you can use "read" and "write", and normallly
these functions are kernel-functions; but if you use
printf, than it's a library, which is NOT found
in the kernel!



> You have no way of knowing what that integer actually
> means

Well... and a DRIVER has not to know, what it means.
As you know, what a DRIVER means in hardwrae-development, then
it's only some transistors, pushing the current through
the electrical lines. But the transistor does'nt know
anything about low-level-protoclos,  doesn't it know anything
about IP, or TCP, or the X-Protocol, or the application, using
the X-Protocoll, or the informations, handled by the application,
or the meaning of the information/data, which the application
process, or the effect of using this information, processed
by the applictaion, which uses the library, which is based on
the kernel-functions, which uses the hardware.


That's the same as a DRIVER of a car, if it is a chauffeur,
doesn't know, if it's ok, to drive to point x,y,z.
He has to drive; the Lady with the costly jewels sasy, where
to drive to; and only she knows, why she drives there and
how much VOLTS she got, when she's going through the door 
in the destination-street with an INTEGER  house number.

The driver only drives the Lady to the adress and SHE
get hot on 10.000 volts on the right integer house number. ;-)



> unless the user-software has some a-priori knowledge about the
> exact hardware (and it's current configuration).  Knowledge that should
> be encapsulated within the driver.

NO!

It should not!

Well... the programmer of an application, which only should
use the voltage-units of the hardware, and don't wan't
to calculate it from the integers, should not do the math...
...but only should recompile the kernel or kernel modules
every time.

A user-space library is compiled without problems; you can
change it and don't have to be a super user.
But if your driver changes, then you have to do more work...
...and it's a very dirty way to implement hardware-specific
things.

Less is more....

> Requiring user software to know

It requires user-space-software; not really user-software.

The difference    kernel space <-> user space


Isn't the same as

harwdare-developper's software <-> user-software



The first difference is, where the code is executed.
The second difference is, which software is where
used.



         


         USER-Software e.g. for doing the measurement of voltages
         LIB for the device-driver
    -------------------------------------------------------
         KERNEL-Modue, e.g. device driver
         KERNEL




[ first line repeated: ]
> Requiring user software to know
> exactly what hardware it's talking to and how it's currently
> configured violates the whole reason for having device drivers in the
> first place.

NO!

You say:         User software   _is the same as_ user-space-software    


You need USER-SPACE-SOFTWARE, but it is software of the developper/vendor.


The difference
                   kernelspace vs. userspace
                                             is NOT the same as

   developper-/vendor-softwrae  vs. user-/application-software !



Do as less as you can do in the device driver. Do the residual
things, like math and so on, in a library, which residents
in user space, but provide an API to the "user" (which is
a software-developper of higher-leveld software than your own,
i think), which does the math stuff and give the user the
voltages instead of the integers (but provide a way to
get really the integers for the freaks and more interested
people...).




> An analogy: if user software had to know what Ethernet
> controller, what phy chip, and what sort of baud rate and magnetics
> were being used in order to open a TCP/IP connection, people would
> scream bloody murder.  Not allowing analog I/O drivers to do floating
> point places their users in that same situation.

There are much more layers in your example then in the
software, you want to write.
And the TCP/IP isn't the same as a table for conversion
of integers to "voltages" (which really isn't a very
heavy problem to implement).

TCP/IP is really a necessary feature of the system.

To get some integers from your hardware, maybe is a problem,
which can be done by a kernel module.
But to use some math to calculate integers into voltages
really is a problem for a program in user-space, feeded by a
file, which the user can take via internet from your website,
if your hardware changes (using the same driver).

The driver shold give the integers. The library should
implement some mathematical computations, based on a file
with some tables for the calculations, delivered with your
hardware.
But the user should be able do put his own calculation-table
into the software (the library you wrote), to calculate OWN
voltage-values, if needed, e.g. if your hardware has to be
used at temperatures, which you don't have calibrated...
(then the user modifies the integer-to-voltage-table-file
and is happy again, using the same driver, don't need to
recompile a module with suoer-user-priviliges, and don't
have to recompile the driver-math-library).

Write your software not like monumentals, write it in modules.

Use the way of "how to write software under unix", if you
write software for a unix-like system.

Then YOU AND THE USER will be happy.

Or, if you think, that all I said is shit (and it's not
my bad english...), than use another platform, where
you can use "all is one": Write a complete aplication
and use it at the same level as your OS.

And if you get trouble (reboot, ....), be happy that you can
use math, where ever you want. :->


> I realize that doing floating point in drivers would complicate
> things, but let's not pretend that there are no cases where it would
> be appropriate.

There is no need to use fp-math in the kernel.

You are in "comp.os.linux.development.system" here.
And linux is a unix-like system with at least as much
structure as a unix system, even if the OSI-modell
has more layers....


> The REAL answer to the question "why can't you do floating point in a
> device driver?" is the same as most other "why doesn't Linux's X do Y?"
> questions:

> Because the people who designed X had no need to do Y.

And there is no need, really no need. Not yesterday,
not today, not tomorrow....


... if you understand, why there is no need, yo'll see that
there is really no need! :-)


> If somebody really wants to do floating point in a device driver,
> they'll hack the kernel to make it work.

Wrong way!

If somebody need to hack the kernel to use math for his hardware,
he's really stupid or don't use the right OS (and then he's OT here ;-)).

If you want math, put it in a user-space library, which
is not user-software. It's software, running in user-space...


Ciao,
   Oliver

P.S.: Literature:  Alessandro Rubini: LINUX Device Drivers,
                   O'REILLY & Associates Inc.


P.P.S:

  "As a programmar, you will be able to make your own choices
   about your driver, choosing an acceptable tradeoff between
   the programming time required and the flexibility of result.
   Though it may appear strange to say a driver is "flexible,"
   I like this word, because it emphasizes that the role of a
   device driver is providing MECHANISMS, not POLICIES.
   The distinction between mechanism and policy is one of the
   best ideas behind the unix design." A. rubini: Linux device
   drivers."
                    (Alessandro Rubini: LINUX Device Drivers)


-- 
In der endlosen Ausrede, "langfristig" werde alles gut, wenn nur kurzfristig
die neoliberalen Rezepte (Lohnsenkungen, Verl�ngerung der Arbeitszeit, Privati-
sierung von Staatsunternehmen, Abbau von Sozialleistungen etc.) befolgt
w�rden, hat der utopische Geist einen Unterschlupf gefunden.    (K.H. Brodbeck)

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


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

Reply via email to