Linux-Development-Sys Digest #848, Volume #6 Sun, 20 Jun 99 14:14:12 EDT
Contents:
remap_area_pages, get_vm_area question (Jason Donovan)
Re: TAO: the ultimate OS (Terry Murphy)
Re: using C++ for linux device drivers (Frank Sweetser)
Re: TAO: the ultimate OS (Terry Murphy)
Re: using C++ for linux device drivers (Frank Sweetser)
Re: Embedded Linux Question ("Jack Coates")
----------------------------------------------------------------------------
From: Jason Donovan <[EMAIL PROTECTED]>
Subject: remap_area_pages, get_vm_area question
Date: Sun, 20 Jun 1999 16:07:33 +0000
This is a cryptographically signed message in MIME format.
==============msD2C2F2019520ED9934274EA9
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Hi!
I need to be able to create a buffer inside phisical memory (at a fixed
address) that will neither get swapped nor moved from the Kernel.
I was looking at the source and it seems to me that the two functions
get_vm_area and remap_area_pages are the once to use...
Would someone be kind enough to clarify this...
Also, is there a reference of the kernel functions?
Thanks a lot!
-DJ
==============msD2C2F2019520ED9934274EA9
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIsgYJKoZIhvcNAQcCoIIIozCCCJ8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlAwggMAMIICaaADAgECAgIruzANBgkqhkiG9w0BAQQFADCByDELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMTMwMQYDVQQLEypDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyBSU0EgSUsg
MTk5OC4yLjI1IDg6MzUxOzA5BgNVBAMTMlRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0Eg
SXNzdWluZyBLZXkgMTk5OC4yLjI1MB4XDTk4MDcwNDE4MTYyMloXDTk5MDcwNDE4MTYyMlow
aTE7MDkGA1UEAxYyVGhhd3RlIEZyZWVtYWlsIE1lbWJlciBKYXNvbi5Eb25vdmFuQEN5YmVy
RHVkZS5Db20xKjAoBgkqhkiG9w0BCQEWG0phc29uLkRvbm92YW5AQ3liZXJEdWRlLkNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuXt2vBq0PLmGTh6XHhFCiqS7yQsFrChdBJVx
KBuprI3qNPnWpICjckUR/MZcnpyqqrxKoApoOxVkBQouZrY7cFPye5Zf1KHGXXwNI7j0hmAQ
Und/NBtDsWimMkYFnF3Q1+3J4C4xtV3mGm4virJAIDGZ9Xf6GX+9TcjefIGKAaMCAwEAAaNX
MFUwFAYJYIZIAYb4QgEBAQH/BAQDAgWgMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA
MB8GA1UdIwQYMBagFO00F24OK15Lh5iRuDenmL+SH6xyMA0GCSqGSIb3DQEBBAUAA4GBAMEM
V5nOFOdJgIcuM9uAl0EFi+fpxeCjEQUy66bPN3bHdl7672XZm41LPMyM+hCWf4UrRlYFyeRl
tlgm8TOCtfhXaeBaXoxBwlTzZaPlj2WJTFzbEBmARwPHRVblsF4Z74PQwKfMHxk3pKHc4c+R
YnqkP0kVMjJ3t0SEVVHsJyqNMIIDSDCCArGgAwIBAgIBCDANBgkqhkiG9w0BAQQFADCB0TEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB
MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDIy
NTA4MzUzM1oXDTAwMDIyNTA4MzUzM1owgcgxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEzMDEGA1UECxMqQ2VydGlmaWNhdGUgU2VydmljZXMgUlNBIElLIDE5OTguMi4yNSA4
OjM1MTswOQYDVQQDEzJUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VpbmcgS2V5
IDE5OTguMi4yNTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxzHDxBuZI3LSUYWVTONZ
kuTobIG19BtfCebErbNEb6o411fksMXLunSuTGEjJHYG+NldDYoosrQr7Q27UiT0t8VJp4Nj
/AoEsO+BKPfmkcZNl+6SdiZiyGM3djyxkg/crVIGinHFNzFqhtu9CGkoWfztx30mZ91N3tPF
Av53tuECAwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWoBRyScJzNMZV
9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQBC6u2LYX6h1FxSqTy9npx56AmLEoGt
jx1aRu3xJSZbyK79eiEWzaAeO5czg/tONyool6ZI9SgYAiR8gHtTULX7b5r8bapcJkWoLzYi
WNMbAgMf7pQ58P40WohLGz2M89d+059wW3b22MTitjwknQkljFmx1Ivz/ASCDp4phmzF/zGC
AiowggImAgEBMIHPMIHIMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQw
EgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxMzAxBgNV
BAsTKkNlcnRpZmljYXRlIFNlcnZpY2VzIFJTQSBJSyAxOTk4LjIuMjUgODozNTE7MDkGA1UE
AxMyVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1aW5nIEtleSAxOTk4LjIuMjUC
Aiu7MAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNOTkwNjIwMTYwNzMzWjAjBgkqhkiG9w0BCQQxFgQU3zUv4sSufaPTLFznPVdxa1wF
2ZowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAHMJ7r
C2zY5FuwvOotyd2kpB6rz1O2i53oeD4gPTX0d2o4OHfmlMScyKYCHmB1KR/wtamNHNtgiEx/
g46VNEDZLn5L0XvS+Og7bs4tGe6RWvh7a5WO/r2JZi3pH8rh8qkd8zSrZtTiiAUMo7r8KO7I
OqEsPZxOMZBVOKtDKNJVng==
==============msD2C2F2019520ED9934274EA9==
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 20 Jun 1999 17:04:10 GMT
In article <7kg38f$kbc$[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>If you read something disparaging in my reference to mainframes,
>then I urge to to read the quote again. Revisiting existing
>concepts is not a step forward. It also is not necessarily a
>bad thing.
The issue of whether an OS should be mainframe-like or Unix-like
is actually pretty interesting. Mainframe OS'es had lots of features,
but they were big and slow for their time. Unix came in and showed
the world, that an OS did not have to be big, and stripped all
"extraneous" functionality. Meanwhile, hardware grew, big time. In
hindsight, though, it can be argued that the mainframe OS'es, with their
insistence of a sheer number of features rather just elegance of
simplicity (i.e. Unix), were ahead of their time. It was not until
recently that they could be implemented to perform well. Windows NT is
much more of a mainframe class OS than Unix is -- however, it has been
very influenced by Unix (e.g. files are streams of bytes), so it ends
up falling into a somewhat in-between class, which is probably why a lot
of people do not like it.
>It was easier to port UNIX than to write an OS from scratch. The
>fact that the principals of comapnies such as Sun cut their teeth
>on UNIX at Berkeley (and liked it, I guess) was also a significant
>factor. BTW, the people who did BSD and SunOS *are* professional
>software engineers (that's at least what their degree says).
>Today, hardware companies do not even dream of developing an OS, and
>no longer consider porting UNIX. They design their hardware to be
>compatible with Windows, and write drivers.
Perhaps in your Microsoft-dominated fantasy world. The fact is there are
no less than five Unix's being slated to run on IA-64 (off the top of
my head, I can think of Tru64, Solaris, IRIX, HP-UX, and SCO...plus
Linux...I forget if AIX is in the works). I'm not even sure there
are that many major architectures which do NOT run Unix, besides some
of the mainframe systems.
>NFS is not a great protocol, granted. Pretending that SMB is any
>better displays your profound lack of knowledge.
I am not saying SMB is a great protocol. I am merely saying fundamental
filesystem features such as mandatory file locking work in it (as well
as DECnet), but not in NFS.
>So what? The basic UNIX file system is designed to store lots of small
>files. When your average mainframe OS was designed, disk space was so
>expensive small text files were stored on paper
I understand that, but this was 30 years ago. Today, most users (whatever
that means) work with large, structured files such as Word documents,
Access databases, Excel Spreadsheets, etc. The era of the small file
is over. And, as I noted above, we now have the hardware to support such
use.
>There's no guarantee that an OS provided index-sequential file will
>be the best support for a relational DBMS (in fact, it isn't).
>Similarly, the locking features of the OS might not be the best
>choice for a DBMS (in fact, they aren't).
If the OS provides optimized record services, then they should be good
for most tasks. I think that is a much cleaner solution than the Unix way,
where everybody who needs a database implements it on their own. Each
program has its own data, and the code to read that data is unique to
the program, which IMHO, is very sloppy. The same is true of the Unix
idea of config files (vs. various database configuration setups in most
other OS'es).
>Do you really mean turning Oracle into a kernel module? Or do
>you want to limit yourself to fixed-length records and index-
>sequential? Oh yes, and if someone needs a structuring not
>provided for by the OS, will you tell him to go and such eggs?
I don't necesarrily mean putting it into a kernel, i.e. running in ring
0. I am less concerned with the details of implementation than the
overall point: there should be a certain shared service to resolve these
types of problems. In the case of RMS (Record Management Services) on VMS,
it is not running in ring 0, but it is a service running lower down.
-- Terry
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 20 Jun 1999 12:57:27 -0400
"John Burton" <[EMAIL PROTECTED]> writes:
> Frank Sweetser wrote in message ...
> >Justin Vallon <[EMAIL PROTECTED]> writes:
> >
> >> [EMAIL PROTECTED] (Alexander Viro) writes:
> >>
> >> > In article <7kdqj9$l1o$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >> > >Hi all,
> >> > >
> >> > > I am working a sound driver for linux (I will probably use OSS).I
> >> > >am planning to use C++, instead of C. Has anyone used C++ before for
> >> > >kernel/device driver programming for linux. If so what are the
> >> > >complications with using C++. I heard that C++ needs some OS support,
> >> > >especially for calls like "new", "delete" and stuff like that.
> >> >
> >> > It will not get it. It's beaten to death many, many times. Oh, and
> forget
> >> > about try and catch - they are not going to work. Ditto for standard
> classes
> >> > - runtime environment is not available too.
> >>
> >> Too bad. All you should need is:
> >>
> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
> >> void operator delete(void *p) { free(p); }
> >
> >...which is a higher-overhead version of
> >
> >#define new((x)) malloc((x))
> >#define delete((x)) free((x))
>
>
> No it isn't, it is very different. malloc and free don't construct the
> objects
> they just alllocate the memory.
yup. but, then, neither do the versions written as non-inline functions up
above. mine also has this flaw, but at least it ends up as a bit of inline
code rather than another function call on every new/delete...
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
"On a normal ascii line, the only safe condition to detect is a 'BREAK'
- everything else having been assigned functions by Gnu EMACS."
(By Tarl Neustaedter)
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 20 Jun 1999 17:56:50 GMT
In article <[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>I don't know about a step back, but I agree with your assessment
>about unix being easy to port. someone suggested unix is very much
>like a virus, (was it Ritchie?) and that much of the reason is
>its EASE OF PORTING. who can deny that unix design criteria have
>largely been centered around EASE OF PORTING for virtually its
>entire lifetime?
That is actually a very good point. Incidentally, you are referring to
the Unix Conspiracy (c.f. the New Hacker's Dictionary) which states
that Unix was plot by AT&T to have all of its competitors runnings an
unreliable and insecure OS. The UHH also suggests that Unix is the
most successful computer virus ever, since it has such attributes as
living on a variety of hosts, being small, and being subject to many
mutations. OK, back to the serious stuff...
>the strong hostility to my essay is evidence of something much
>deeper in the psychology of hackers. they do not want to consider
>new priorities that are beating down their doors by the mainstream
>public and natural evolutionary forces operating in the
>software industry.. (yet dare I say they are inevitable/
>unstoppable).. it is strange how hackers seem to embody the
>same hubris that IBM did with the invention of the PC, but I
>find it to be unmistakably present.
Yes. A lot of Unix people seem to find it very difficult to think
outside of the Unix box, i.e. they have almost a natural reflex to
react negatively to things such as adding things to the kernel, file
types, etc., anything that goes against the Unix philosophy, without
going into much technical detail.
>the new priority: THE END USER. everything needs to revolve around
>the end user, rather than the programmer. EASY TO PORT== favoring
>the programmer.
I totally agree, of course. One of the problems you are going to
encounter with this philosophy, I'm afraid, is management. Management
loves the concept of portability, and that's precisely why Unix is so
commercially successful, both from the makers of Unix who can quickly
and cheaply get a Unix running on a new system, and from the users of
Unix, who have a warm, fuzzy feeling that they can move between
different vendors easily. It is interesting to note that even Windows
carries this over, with the port to Alpha.
However, the RISC wars of the '80's and '90's are over. Right now there
is basically one architecture that really matters, and it will be
really, really interesting to see what happens in the next 10 years to
IA-64 which basically all systems makers (from desktop to enterprise)
plan to embrace. If it is as successful and some predict, portability
may hardly be a concern at all anymore.
>a good example of how the OS simply fails to enforce certain
>very rudimentary kinds of discipline. very much reflective of
>the hacker ethic of freedom bordering on chaos. well imho,
>structure can make life much easier.. and ultimately I'm sure
>the market will agree in a few years<g>
I totally agree on structure/discipline being necessary for projects
such as these. My main professional experience has been on the hardware
(chip) design side of the industry, where you only get about two
chances at a working product. The design process is very methodical,
and every transistor and wire is planned and validated before it ever
gets into silicon. The software process is much less methodical;
anybody with a text editor and a compiler can make a change to a
software system, and see the results (in the actual product) in a few
minutes. The whole concept of a quick edit/compile/test has meant
virtual death to the formal software design and test process. No other
engineering industry is permitted to make changes with such little
thought.
I actually have very little faith in the software industry. The fact
that Unix (especially) and Windows are the best that anybody has come
up with in thirty years speaks volumes for the lack of discipline in
the industry. I don't say this to discourage you, but rather to warn
you to not fall into the same pitfalls.
You have been criticized for not creating a design document (and not
having code, but that just empahizes my point above). The formal
software process states that there is one document before the design
document, called the requirements document, which is precisely what you
wrote. My advice to you is to gather the people who are interested in
the project, and come up with a design document. The formal software
design process is difficult, especially if you don't have a manager
hanging over you to produce it. I do think it will be difficult to
produce a well designed system in the free software world, but it
certainly can be done (GNOME, for example, seems pretty well designed).
-- Terry
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 20 Jun 1999 11:30:26 -0400
Justin Vallon <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Alexander Viro) writes:
>
> > In article <7kdqj9$l1o$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > >Hi all,
> > >
> > > I am working a sound driver for linux (I will probably use OSS).I
> > >am planning to use C++, instead of C. Has anyone used C++ before for
> > >kernel/device driver programming for linux. If so what are the
> > >complications with using C++. I heard that C++ needs some OS support,
> > >especially for calls like "new", "delete" and stuff like that.
> >
> > It will not get it. It's beaten to death many, many times. Oh, and forget
> > about try and catch - they are not going to work. Ditto for standard classes
> > - runtime environment is not available too.
>
> Too bad. All you should need is:
>
> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
> void operator delete(void *p) { free(p); }
...which is a higher-overhead version of
#define new((x)) malloc((x))
#define delete((x)) free((x))
> Compile with -nostdinc++ -fno-exceptions.
>
> Static constructors may need a C++ link phase, or you could warn that
> C++ static constructors will not be executed.
don't forget about name mangling, call by reference, the whole
private/public/protected mess...
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
Woody: What can I do for you, Mr. Peterson?
Norm: Elope with my wife.
-- Cheers, The Triangle
------------------------------
From: "Jack Coates" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.m68k,sci.electronics.design,sci.electronics.misc
Subject: Re: Embedded Linux Question
Date: Sun, 20 Jun 1999 10:24:56 -0700
check out www.linuxrouter.org and www.calibri.com for ideas. The linux
router mailing list is currently in discussions on several ways to build
embedded systems with JumpTEC DIMMs, Advantech biscuits, &c.
Jack
Adam <[EMAIL PROTECTED]> wrote in message
news:ON_a3.94$[EMAIL PROTECTED]...
> Hi:
>
> I have an idea I want to implement. The foundation of this idea resides
on
> an embedded controller (I personally like Motorola) running a symplified
> version of a full-blown operating system (easier to develop "embedded"
> applications using exisiting kernels, and APIs).
>
> What I have in mind is a Motorola 68K series processor/controller, running
a
> stripped-down version of Linux. I've seen solutions using a pentium SBC
> with a 3.5" Hard drive attached to it -- thats too bulky for what I want
to
> do.
>
> Instead of using a hard disk, I was thinking of using Flash memory for the
> ROM section (this would store the operating system, system software -- to
> flash the ROM portion when the OS needs updating, etc..) and standard
DIMMs
> for the RAM. The thing I can't understand (or grasp) is how Linux would
use
> RAM as it's file system.
>
> Taking Linux from a destribution like Red Hat for instance, it's
configured
> to look for an IDE or SCSI boot device (file system). How do I take that
> and make it boot from flash memory. After linux is booted I'm assuming I
> can use some of my available RAM and create a ramdisk (the same way I
would
> on a desktop PC running linux) and use that as my file system for
temporary
> storage.
>
> I've seen exisiting solutions for what I'm looking for already, but I
would
> like to design my own.
>
> Any help would be apprechiated.
>
> -- Adam.
>
>
------------------------------
** 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
******************************
