Linux-Development-Sys Digest #633, Volume #7 Mon, 28 Feb 00 09:13:18 EST
Contents:
Re: glibc development language (Alexander Viro)
Re: ioremap() and PCI devices (Colin Higgs)
Re: lowlevel and highlevel hardware access (NoProblem001)
Re: Linux or Windows (NoProblem001)
Re: Upgrading very old kernal. (NoProblem001)
Re: How debug linux modules ("KPG")
Re: complex math in a device driver (Glen Turner)
Re: complex math in a device driver (Gordon Haverland)
Why a file system ? (Nicolas Boulay)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: glibc development language
Date: 28 Feb 2000 06:05:38 -0500
In article <8947kb$[EMAIL PROTECTED]>, tye4 <[EMAIL PROTECTED]> wrote:
>
>Christopher Browne <[EMAIL PROTECTED]> wrote in message
>news:bM0t4.37328$[EMAIL PROTECTED]...
>> Centuries ago, Nostradamus foresaw a time when tye4 would say:
>> >The GNU guidelines in http://www.gnu.org/prep/standards.html
>> >state that it is better to use only C for glibc development.
>> >I've been developing C++ code for glibc. Is this a strict requirement
>> >or is it okay to use C++ for glibc
>>
>> I think you're confused.
>>
>> Only C is used to develop GLIBC, because GLIBC is a C-oriented
>> library. It might be well and nifty to write portions of GLIBC in
>> Intercal or Emacs Lisp; that would *not* be a good thing for anyone
>> that intends to actually deploy GLIBC.
>>
>I'm not confused. C++ can indeed be used to develop libraries for C
>programmers.
>extern "C"
>{
> void c_func1(int foo, int bar);
>}
>
>C++ is a standard for all these years. I don't quite understand the
>reluctance in using C++ for system development in Linux.
Nausea? You know, vomit makes keyboards stuck and not everyone got
sufficiently strong stomach... That, and lack of examples where C++ would
be successfully used for system development. Probably related to the previous
reason... Heck, even in NT kernel (and I suspect the core libraries) are
in C - C++ is used for GUI crap atop of that. And no, Be is not a valid
example.
It's UNIX, deal with that. If you want to use C++ - fine, just stay
the fsck out of the core stuff when you get such an urge.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Colin Higgs <[EMAIL PROTECTED]>
Subject: Re: ioremap() and PCI devices
Date: Mon, 28 Feb 2000 11:19:11 +0000
Steve Johnson wrote:
> I am doing pretty much the same in a driver that I am writing, and appear
> to be reading/writing OK. (GT64115_reg_map is a register map for a chip)
>
> [Code snippet]:
>
> volatile GT64115_reg_map *p;
>
> /* Map the 4KB Internal Registers region. */
> deviceinfo.vaddr=ioremap(deviceinfo.regions[eInternalRegisters].addr,
> deviceinfo.regions[eInternalRegisters].size);
> p = (GT64115_reg_map *)deviceinfo.vaddr;
>
> p->AddressDecodeError = 0x0;
> etc..
>
> I wonder if the problem is that your tmp_read_word isn't volatile and
> is being cached?
> I don't use the readw() or writew() functions.
Thanks for your reply. I eventually managed to find a proper I/O region
using code like:
/* find the I/O ports */
for(i=0;i<6;i++){
base=pcidevp->base_address[i];
if(!base)
continue;
if (base & PCI_BASE_ADDRESS_SPACE_IO) {
/* there's only one set of I/O ports so this must be it */
s->iobase = base & PCI_BASE_ADDRESS_IO_MASK;
}
}
and succesfully used inw and outw on s->iobase (s holds state info for
the device). It turns out the I/O address was stored in base_address[2],
where the manual (of course) did not have anything listed ...
When I get time I will try out your suggestion and try an experiment
with volatile variables - just for the sake of curiosity, but for now I
have my I/O working :).
--
Colin Higgs,
Chemical Engineering
University of Edinburgh Email: [EMAIL PROTECTED]
King's Buildings, Mayfield Road, Tel: +44 (0)131 6508557
Edinburgh, Scotland, EH9 3JL Fax: +44 (0)131 6506551
------------------------------
From: [EMAIL PROTECTED] (NoProblem001)
Subject: Re: lowlevel and highlevel hardware access
Date: 28 Feb 2000 11:28:06 GMT
>I'd like to understand hardware access in Linux. How does it work?
>
Judging by my email address, I'd hardly qualify as a system code guru for
Linux! :) Even so, we backslash-grounded people can port what we know while
we learn.
Let's just assume that you program in C++ for DOS in Turbo C++ 3.0. In that
case, while you mess around in "your native environment", go into the options
menu, and try a little masochism on for size. Make the darned IDE always
default to a filename.c.
Then write stuff that parses out and sorts and analyzes and does all kinds of
automatic stuff with the text files you read. Make sure that every source code
file starts like this:
#include <stdio.h>
#include <string.h>
#include <dirent.h>
That's it. No cheating.
stdio.h while in DOS teaches a person more about UNIX culture than most pricey
"Linux in the Fast Lane" kinds of Barnes and Noble stuff.
FILE *mystream;
Now there is a thing that a person can sink her or his teeth into. Did you
know that it is of the very same species as the default of cout and cin? It is
an indirect connection though.
I mean stdout and stdin.
Even if your "home turf" compiler isn't the same, go into its directory tree
branch, specifically c:\tc\include\ or somesuch.
Then open stdio.h in a text editor. Look for the struct, FILE. Then snoop
around a little more until you find what stdin and stdout are.
If you code this,
myInt = fileno(mystream);
and then if you code this,
myInt = mystream->fd;
and after you realize that they are one in the same, you've accomplished more
in the "brain porting" to Unix culture's API than you realize.
fd in open systems computing is like sugar in a bakery.
stdin->fd is always 0. stdout->fd is always 1
If you code,
mystream = fopen("filename", "rwt");
then if you snoop with
myInt = mystream->fd;
Then you start to realize that your open file and your stdout and your stdin
are all the same sort of critter.
Design a program, and call it doneto.c
Design another, and call it doto.c.
Whatever is to be the input of doneto.c--say, what a person would type while
answering that program's questions, using only fgets() with a subsequent
sscanf() as documented--can stand on its own.
Then make your doto.c program a blabbermouth through stdout. Just do a whole
bunch of printf() stuff.
Then go to the DOS prompt, and type
doto | doneto
After you have played like that, you start to coerce streams, which are of type
FILE *.
That's where it's at.
You want to access hardware?
You already know how, provided you do it in an open systems environment.
Just as the "thin sysadmin manual" says to help you install some Linux
distribution, everything in Linux is a file. Well, guess what? Devices behave
like files with behaviors other than pwd, ls, cd, and find.
The same stuff you learned "at home" in DOS applies here but more. You can
open a device just as you would a file. That device gets an fd, which is a
file descriptor.
However, this time it matters. Big time.
You ask,
>What are the different possibilities of accessing hardware like
>printers, scanner, gamepads, soundcards, keyboard, graphic cards and
>mice.
>
The short answer is "A heck of a lot more accessibility than anything in DOS,
Windows, or Macintosh O/S."
In other words, possibly 60% of the answer to your question is off topic. With
exceptions addressed by ioctl() and the not-really-a-device-driver for X
Windows, the applications programming interface of devices is the kernel's
problem to deal with and your playground to play in AS AN APPLICATION
PROGRAMMER.
As it happens, everything you mentioned is a character device with the
exception of the graphic cards and possibly the gamepads.
fprintf() does the talking
fgets() and then sscanf() does the listening, more or less.
If you want more low level control, you can still stay inside the ANSI API.
Instead of fread()ing, you can grab that mystream->fd and do a read(). You can
do a write() instead of a fprintf().
fseek() can move you around if you are in a block device.
Most of the time, you don't have to get much lower than that. The culture of
UNIX is very very keen on preventing the necessity of reinventing the wheel.
When there is almost never a profit to be made by shrinkwrapping, that is how
it goes.
If you still want "inside", probably the order of things to play with are as
follows:
1. mkfifo as documented in the Linux Programmer's Guide
2. an example of a device driver given by the following command
# find /usr/src/ | grep .c | grep skeleton
3. an official book's "absolute necessities list" of functions to be defined
within a device driver
3. the ISA specifications, the boring details of hardware resource nitty
gritty, and the layering of networking protocols
4. an understanding of Linux politics. (For example, it is extremely rude to
hook an IRQ as would a DOS programmer, whether in assembly language for a TSR
or in C for an application's specialized needs in user space.)
>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 :-(
>
Information:
"Red Hat Linux Unleashed"
"Official Linux Programmer's Guide"
the source code files and header files, specifically to get a feel for which
functions are mandatory and the general catagory of work they do and the norms
of building structures.
Libraries:
I get a strong feeling that you and I are a lot alike except that I would be
willing to bet that you have invested considerable time into trying to figure
out the most effective ways to program binary executables (i.e., real ones
without vbrunx00.dll) for MS-Windows.
That "presumption" that you need to get a special layer BETWEEN you and the
devices gives me that impression. When someone peddles a .dll, it is not to do
you a favor insofar as you feel hardcore API access is in your best interests.
It is generally ostensibly to "reduce costs in coding time" which means to
hopelessly wrap you until you are so cozy that you haven't a clue where your
code is connected to anything except the "rapid application development suite".
In the terms of the predators who push that stuff, that is "successful
strategic marketing".
I confess win32 ignorance. I did not cut my eye teeth with a Unix terminal,
but I don't appreciate the appropriation of "standard API's". I spent just
enough time in Borland's "alternative" to MFC (OWL) to realize that the
documentation was a combination of a Siren's song and a crack dealer's first
"free" dose.
Methinks you are much more expert than I in those object-oriented endeavors.
Don't think that means that there is any feeling of superiority of the people.
It's the open systems CODE BASE that is better.
If I would practice more often what I preach, then it wouldn't be AOL that
collects these keystrokes before posting!
I've tried (too much?) to read between the lines of your posting. If I'm
right, then this can be a help. If not, oh well. I tried.
Most of what I posted here is opinions pertaining to pedagogy. I'm learning
stuff across the DOS/Linux "barrier". If I misperceive something or if my
level of expertise is too low for this general sort of commentary, please
precisely correct this thread before it gets stuck in the wrong position. :)
------------------------------
From: [EMAIL PROTECTED] (NoProblem001)
Subject: Re: Linux or Windows
Date: 28 Feb 2000 12:37:59 GMT
>I am debating wheather to run Linux on my computer or to stick with windows.
>
<snip>
>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.
>
What you need are general hints with possibly a little specificity.
If you think your MS-Windows addiction is pretty strong (as mine obviously is),
my recommendation is for a "flavor" of Linux hat is a tad on the "consumerist"
side. SuSE (which means you get to look east instead of across the Atlantic at
us Yankees all the time ;) uses a graphical user interface to login if that's
what you want, and it can fire up X Windows as automatically "by default" as
MS-Windows. I bet you'd like that.
Another think I think you would like is the "default" hugemongous quantity of
application software that comes cheap from SuSE. Obviously, I spend dollars,
which might not have anything to do with your (VAT-oriented) situation, but for
only 35 American dollars, I got 6 cram-packed disks from SuSE, and the
documentation in the paper manual is "in levels" so that the depth of your
background is taken into consideration.
Where SuSE is weak is in the steps BEFORE installation. If you can scrounge
one, get a new or old copy of Red Hat Linux, and get the DOS tools from that
CD-ROM (or from their generous Website at redhat.com).
You need to partition your hard disk drive. I know others have said that
another drive should be used, which is all fine and good, but when your
computer starts up, it is a lot happier when it can look at the first hard disk
drive, see some hardcore specific info about any available operating system
startup code, and then go from there as the computer boots..
Putting all the start-uppable partitions on one drive is not mandatory, but
when you try to do another scheme, what happens is that you need to be an
expert right away because you have to do a thing with liloconfig.
One more thing that is important to a newbie. SuSE is probably cheap because
YaST is what it says ("Yet Another Setup Tool"). Germans are great engineers;
of that there is no doubt, but they don't make a lot of boutique-like fuss for
the sake of user friendliness. If you can just hop that first hurdle, IMHO,
you should be ok.
I know that looks like a contradiction, but take the help system as an example.
They engineered it pretty well, particularly for a Netscapish MS-Windows user.
You can choose the layout plan (what we call "the window manager" with
artistic motifs--no pun intended--that can keep you comfy in a couple of
different variations of the Windows 95 theme). Other companies do too, but
SuSE makes a consistent graphical setup tool an awful lot like Microsoft's "on
the outside" without angering the folks who tweak with text files "on the
inside". The different window managers that are available get altered
according to different 'language" schemes of text file alterations, but SuSE
has "GUI'd" all of that in a reasonably slick way.
I have absolutely no gripes against Red Hat. In fact, it's the only
distribution that I have currently loaded, and I was so satisfied with the
1995/96 version (3.03) that I have not yet installed the SuSE system that I
just praised!
Then again, I just want to do some C programming and learn about the
fundamentals of the Linux kernel for now. For me for now, a superficial
exposure to the user-level stuff is all that interests me. Obviously, I am
using Microsoft code because that is all that works directly within AOL (even
the Mac!).
But I am not you, and that is what is nice about Linux in general. It is
extremely flexible in matters of functionality and tastes and diverse
priorities. Red Hat, SuSE, Caldera, Debian, Hard Hat Linux (Monta Vista), and
many others all do their own interesting things, but where it really counts,
there is solid consistency.
I guess you'll find disagreement among people on stuff like this, but I hope
that when it adds up, you will find your course of action your way.
:)
------------------------------
From: [EMAIL PROTECTED] (NoProblem001)
Subject: Re: Upgrading very old kernal.
Date: 28 Feb 2000 12:49:53 GMT
I propose the notion that a person should just copy all personal files to
another partition and then do a "Draconian" install as would be the case with
MS-Windows NT in its so-called "upgrades".
After a hard disk addition (to my other two), I had to put something bootable
in, so I reinstalled from the same distro as the installation earlier (also Red
Hat with 1.2.13 kernel, also with a book).
Now, to be honest, I have cold feet about my SuSE distro even though I like its
documented features. I have a lot of my own C code in there on my ext2
partitions, and I can tuck it away where it won't get clobbered, but I am still
not sure if I can take my own advice without regret. The places where files go
would be somewhat altered.
Would someone please debate this in some detail?
------------------------------
From: "KPG" <[EMAIL PROTECTED]>
Subject: Re: How debug linux modules
Date: Mon, 28 Feb 2000 14:05:42 +0100
I've been writing on a standalone LINUX system and source level debugger. If
you're interested I'll send you a BETA copy. You will need a monochrome
(HERCULES) card and monitor though.
Regards,
Klaus P. Gerlicher
Diamond/S3
Hernan <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> i want learn how to write linux network devices drivers, so i want trace
> a module to look how it work, if any body know how it work i apreciate
> your help Thanks Hernan
------------------------------
Date: Tue, 29 Feb 2000 00:06:43 +1030
From: Glen Turner <[EMAIL PROTECTED]>
Subject: Re: complex math in a device driver
Grant Edwards wrote:
>
> >Why should you use math in a device driver?
>
> To provide a layer of abstraction. 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.
This is usually done with integer scaling and a precomputed table.
In fact, the read() from your device driver would probably return a
scaled integer (eg: an integer with units of tenths of volts) rather
than a floating point number in any case. Use an ioctl() to collect
the scaling value, this will allow the API to service a lot more
hardware.
Say you have an 8-bit analog to digital converter, you code a table
that says:
ADC value 0.1V units
1 1
2 2
3 4
... ...
100 224
... ...
255 -1 <-- an "out of range" value
It's common to have a floating point user-space program that writes the
C array, so you don't have to do all the calculation by hand. This
is simple enough to organise from a Makefile. The generated file
traditionally has a ".i" (for "include") suffix and this suffix
is recognised by the builtin Makefile rules.
You might need to interpolate values to keep down the number of table
entries. Newton's method works fine with scaled integer values. Just
get the halting condition bullet-proof.
If the values are particularly non-linear, then you should have more
table entries in the non-linear section (in fact, enough so that the
allowable error E isn't exceeded) and search the table using binary
search before doing the interpolation. You should weigh the interpolation
function to err on the correct side.
If the values are linear and the range is small, you can use the ADC
value as an index into the table, rather than explicitly store the
ADC value.
A good Linux device driver would load the table and any interpolation
parameters as a module, and then assign the table to the particular
device using a device option. Most ADCs have the same register set,
but differing ranges, so you avoid writing the same device driver
again and again.
Depending upon your device and environment, you may also need to load
the temperature correction coefficients from a module but allow them to
be overridden by an ioctl().
If your library has "Starting FORTH", go an borrow it now, as the
description in there of scaled arithmetic and the example of non-linear
interpolation is one of the best.
> 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.
No. It's an engineering decision. Essentially the kernel would
then save to save the floating point state much more often, and
this would slow things down a lot. Also, the math functions
contain a lot of tables, and this would increase the kernel
real memory footprint.
Your problem has been solved this way before. For example, Cisco's IOS
measures the voltage rails and temperature within its high-end routers
without using floating point code.
--
Glen Turner Network Engineer
(08) 8303 3936 Australian Academic and Research Network
[EMAIL PROTECTED] http://www.aarnet.edu.au/
--
Earth is a single point of failure
------------------------------
From: Gordon Haverland <[EMAIL PROTECTED]>
Subject: Re: complex math in a device driver
Date: Mon, 28 Feb 2000 06:26:55 -0700
Grant Edwards 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. 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.
Why not do a table lookup? Your N bit A/D converter returns
a
number, do a lookup of that number to convert it to volts,
or whatever.
Gordon Haverland
#include <disclaimer.h>
------------------------------
From: Nicolas Boulay <[EMAIL PROTECTED]>
Subject: Why a file system ?
Date: Mon, 28 Feb 2000 14:46:59 +0100
Reply-To: [EMAIL PROTECTED]
I know it's look like a very odd question.
But in fact, file system it's a way to stock file. Files are from 2
types : program and data.
If you code, we can say that your program are data. But usualy, you
nevermind absolutly about all the file under the directory of an
application. You use the application and create some datas. Sometimes,
you have the same data for differents applications.
So, you need a kind of data base with your data connected to the
application which can read it (throught the MIMe type ?). And the
application are only visible by her name, not by a sudirectory and 100
internal files plus some link.
For expert, it could look strange to think like that. But for a
beginner, it's more logic. Maybe we can imagine that the used program
can only see their datas, it could be great for security reasons. And
libraries could be managed by such system linked to program with a
system to better manage dependancies. So you could remove a programm
without any problem and you can warn the user that some documents could
not be read any more that a library is not useful any more (and you
don't leave the remove function of the application to do it because
(microsoft syndrom) it could remove a library used by an other programm
or never delete their own odd library and your system become bigger and
bigger ;o) ).
I know that replace file system by data base is not possible because of
the performance. But i have read that
hurd contain some fonctionnalites to see a programm or file like a
subdirectory. And i imagine that it's possible to have a file system and
a data base with pointer on it.
I have read some months ago that microsoft want to include sql server in
it's new OS.
This kind of ideas came to me when i try to manage the 300 Mo of
documentation or application download on the net, or when i try to
refind a data file which i can't remember where i put it. Or when (on
windows, soory) i move a directory to clean my HD but finally it's crash
the system. In fact, this system could looking for what you doing and
made some alarm.
I know that there is many means to answer to those question. Using find
or locate, creating it's own little data base to manage
documentations and never work under root login. But this problem appears
every days, usualy a common user, erase this partition every
4 months to have a clean system. I know that i speak for Wxx. But for
linux, if you don't manage to install correctly in the good directory
your application in tgz, your system could become very dirty in few
month.
I know that you can used rpm or some other pakage manager but each
distributions have their own system. And i beleave that the power of
linux is the source. So why not create a pakage manager which contain
only the source and make the compilation with the information given by
the system ?
The idee is to have a global answer to all of his question. Maybe i
think too big or to complicate. Or i forgot some important point. So i
wait for your comment.
nicO
------------------------------
** 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
******************************
