Linux-Development-Sys Digest #958, Volume #6 Tue, 13 Jul 99 21:14:04 EDT
Contents:
announcement, OS-edge mailing list (Vladimir Z. Nuri)
Re: NT to Linux port questions (Andi Kleen)
Re: Why not C++ (Peter Samuelson)
Re: announcement, OS-edge mailing list (Tristan Wibberley)
Re: embedded linux in a specific application... (Sitaram Chamarty)
Re: MICROSOFT LINUX DISTRIBUTION (Christer Sandvik)
Re: Project problem - linux printer port (David B Anderson)
Re: when will Linux support > 2GB file size??? (Christopher Browne)
syslog vs printk (Yung-Hsiang Lu)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy
Subject: announcement, OS-edge mailing list
Date: 13 Jul 1999 20:41:05 GMT
OS-edge
http://www.egroups.com/group/os-edge/
The OS-edge list is for discussion of recent trends and
the latest advances in operating system design and construction.
Discussion topics are not focused on a particular OS but in
considering new improvements and innovations in any operating
systems known or familiar to subscribers, including commercial,
experimental, and research-oriented. Some but not all of the OSes
that are specifically of interest:
- Unix/Linux
- Windows 95/98/2000
- Windows NT
- Macintosh
- Mach
- Be
- etc.
The discussion will ideally focus on the task of creating a
fundamentally new OS that combines all the best features of all
existing OSes while minimizing the undesirable ones. Advocacy of a
particular OS in its current form as inherently superior in all aspects
is discouraged.
Particularly sought are up-to-date reports of the progress made
and directions taken in different active OS development efforts.
OS features and attributes of particular interest are:
- easily installed/maintained
- fault tolerant
- uniform, cohesive, universal, e.g. entirely object oriented
- "user conscientious", i.e. usable by the nontechnical
- open source/noncommercial
- collaboratively developed
- high performance/optimized
- tightly standardized
- secure, e.g. virus proof
- high integrity/reliability, i.e. incorruptable
- streamlined abstraction, e.g. user insulated from low level elements
- hotfixing, plug-n-play, etc.
- upgradeable/backward compatible
- device independent
Summaries of poster's opinions are preferred to short responses
and message-quoting. The moderator is responsible for guiding
the discussion, and complaints about the contents or traffic of
the list should never be posted but instead be forwarded to the
moderator who will collect, validate, and summarize them.
The moderator is V.Z.Nuri, with B.S. in software engineering
who has used the internet since 1989 and started
programming at age ~10 on a Commodore PET. V.N.
has long contributed to internet discussion groups and forums. V.N.
has used Atari, Apple II, DOS, Macintosh, Windows, and Unix all
very extensively. V.N. has used Linux since ~1996 and has
closely watched its development. V.N. is the author of the
Tao operating system requirements document calling for a
fundamentally new system which can be found at
http://www8.pair.com/mnajtiv/tao.html
TO SUBSCRIBE, send a message to [EMAIL PROTECTED]
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: 13 Jul 1999 22:42:49 +0200
Tristan Wibberley <[EMAIL PROTECTED]> writes:
>
> Cheap, V. Cheap.
>
> I'm not sure of the exact details, but (basically and in principal). A
> new stack frame is created (push the saved IP, push the saved BP and
> assign the saved SP into BP) and the handler is executed (restore the
> task state other than SP, BP and IP, which are set for the handler),
> then the handler exits (ret) and your program continues exactly as if it
> had just called a function (ie, as if nothing had happened - other than
> what data the handler altered).
Actually, it always reenters the kernel into sigreturn(), which does some
book keeping like signal unblocking and then jumps back (into kernel or
into user space, depends if it interrupted a system call and if the signal
has SA_RESTART set)
If the libc doesn't set SA_RESTORER (most don't) there is also some small
overhead, because the kernel needs to write sys_sigreturn trampoline onto
the user stack, and self modifying code causes nasty pipe line stalls.
Even with all that, signals are still pretty cheap, I wouldn't worry
about their performance. The poll/select afterwards to check again for the
event is probably worse.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: 8 Jul 1999 01:50:51 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Ed Bruce <[EMAIL PROTECTED]>]
> So if my mistake was claiming is was the first hyped OOPL. So be it.
> Doesn't change the fact that C++ was hyped big time, at least on the
> government contracts I've worked on.
Yeah, it certainly has been. I guess the sticking point was "first".
Smalltalk, for example, got more than its share of hype, long before
C++ ever did, though maybe on a smaller scale and in different venues.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy
Subject: Re: announcement, OS-edge mailing list
Date: Mon, 12 Jul 1999 20:44:28 +0100
Reply-To: [EMAIL PROTECTED]
"Vladimir Z. Nuri" wrote:
> The discussion will ideally focus on the task of creating a
> fundamentally new OS that combines all the best features of all
> existing OSes while minimizing the undesirable ones. Advocacy of a
> particular OS in its current form as inherently superior in all aspects
> is discouraged.
>
> Particularly sought are up-to-date reports of the progress made
> and directions taken in different active OS development efforts.
> OS features and attributes of particular interest are:
>
> - easily installed/maintained
> - fault tolerant
> - uniform, cohesive, universal, e.g. entirely object oriented
> - "user conscientious", i.e. usable by the nontechnical
> - open source/noncommercial
> - collaboratively developed
> - high performance/optimized
> - tightly standardized
> - secure, e.g. virus proof
> - high integrity/reliability, i.e. incorruptable
> - streamlined abstraction, e.g. user insulated from low level elements
> - hotfixing, plug-n-play, etc.
> - upgradeable/backward compatible
> - device independent
may I suggest that:
> - easily installed/maintained
> - "user conscientious", i.e. usable by the nontechnical
> - streamlined abstraction, e.g. user insulated from low level elements
Can be built onto any sufficiently well-structured, componentialised
system in any way the implementor sees fit, and need not be considered
in OS design. The factor that *does* need to be considered is one of
component-tracking (including versioning).
> - tightly standardized
Standards are irrelevant in cutting-edge design. The important thing is
that any distribution be of a stabilised version which will not be
altered significantly.
I congratulating you in moving on from a wishlist to what could become a
very useful discussion group and resource. I think you should be
prepared to not develop TAO with this group, but link the discussions
that arise to the development of TAO. This would simply be good
management. I would also suggest that you don't moderate too early in
the groups evolution because topics will be difficult to start until you
reach a critical mass - then few will be interested.
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (Sitaram Chamarty)
Crossposted-To: comp.os.linux.networking,comp.os.linux.misc
Subject: Re: embedded linux in a specific application...
Date: Tue, 13 Jul 1999 21:28:59 GMT
On Mon, 12 Jul 1999 17:26:26 -0400, William Ryder
<[EMAIL PROTECTED]> wrote:
>As a refresher, I work for a group considering Linux in an embedded
>application using a MIPS processor and a Galileo support chip. We are
>defining embedded as meaning "diskless, file system-less, and bootable
>from prom." Topics under discussion on our end include:
I don't know any answers to what you asked, but
http://wearables.stanford.edu may have some pointers. Good luck.
------------------------------
From: [EMAIL PROTECTED] (Christer Sandvik)
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: 13 Jul 1999 21:28:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Samuel Brown) writes:
> I had a someone tell me that Microsoft will sell their own linux
> distribution. Is this true?
>
> They said it would have IE 5 and EXPLORER as the window manager
> and the setup program would be really simple.
> It will have word and excel 2000 also.
> Are they taking over LINUX?
>
DO NOT THINK SO.
You may heard that Microsoft have created their own anti-Linux group.
I think that's true...
//Christer Sandvik. ...Do not reply this message.
I'm about to upgrade Knews.
ALAN COX IS A GOD!
------------------------------
From: [EMAIL PROTECTED] (David B Anderson)
Subject: Re: Project problem - linux printer port
Date: 13 Jul 1999 21:52:48 GMT
In article <[EMAIL PROTECTED]>,
Peter Allen <[EMAIL PROTECTED]> wrote:
>David B Anderson wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> smith <[EMAIL PROTECTED]> wrote:
>> >Project problem - linux printer port
[ ]
>> You might find the book
>> Writing Linux Device Drivers
>> by Alessandro Rubini
>> Pub by O'Reilly
>> useful. It seems surprisingly easy to
[ ]
>This leads on to my problem brilliantly. Thanks David :-)
>First I think the original posters problem is that /dev/lp0 is
>designed to run printers. If you read the source (drivers/char/lp*.c)
>then it has got things like excepting interupts on the
>rising pulse rather than on the top. /dev/parport* looked
>good, except they didn't work for me, so I used the code
>from WLDD ^^^^^. (It is available from
>ftp://ftp.oreilly.com/published/oreilly/linux/drivers/
>
>I tried to compile it using gcc 2.7.3, which seems
>to have tightened up its type checking, as I got lots
>of warnings about incompatible pointer types.
>Then the killer error,
>cc -D__KERNEL__ -DMODULE -Wall -O2 -I/usr/include -c short.c -o
>short.o
>short.c:177: warning: initialization from incompatible pointer type
>short.c:178: warning: initialization from incompatible pointer type
>short.c:184: warning: initialization from incompatible pointer type
>short.c: In function `short_i_read':
>short.c:199: wrong type argument to bit-complement
>short.c: At top level:
[ ]
> interruptible_sleep_on(&short_queue);
> if (current->signal & ~current->blocked) /* a signal arrived */
>// The error is here ^^^^^^^^^^^^^^^^^^^^^^^^
> return -ERESTARTSYS; /* tell the fs layer to handle it */
Your friend here is -E
cc -E -D__KERNEL__ -DMODULE -Wall -O2 -I/usr/include -c short.c >junk
In junk, you will find blocked is a sigset_t, which *used* to be
a long according to comments,
but is now a struct containing longs
(~ of a struct won't work!).
So the code must just be fixed a bit.
The short.c:177: warning: initialization from incompatible pointer type
worries me as the signature of the short_read function does not
match the foperation read pointer
(say for the read member and the short_read
function, line 177) type. However, if the call
used does the right things...
but I did not follow up on that, so no guarantees from me!
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Reply-To: [EMAIL PROTECTED]
Date: Wed, 14 Jul 1999 00:32:08 GMT
On 13 Jul 1999 00:28:24 -0400, Byron A Jeff <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Robert Krawitz <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Bones) writes:
>-
>-> >On Sun, 11 Jul 1999 01:31:04 GMT, [EMAIL PROTECTED] (Christopher B.
>Browne) wrote:
>->
>-> >I suspect that the "64 bit support on 32 bit architectures" thing will not
>-> >happen quickly or soon. IA-64 should come out fairly soon, which will add
>-> >up to *several* 64 bit architectures that should be suitable for those that
>-> >really need big files. And that availability should diminish the urgency of
>-> >"fixing" the problem on IA-32.
>->
>-> Plus pushing the issue now is kind of trivial, as another poster
>-> pointed out, because of the small percentage of users who actually
>-> need to be able to manipulate files >2GB.
>-
>-This "average user" thing is a nonsense, because there's no such thing
>-as an "average user". For that matter, the percentage of users who
>-need, say, support for a Matrox Millennium is considerably less than
>-50%.
>
>Substitute "a majority of" for "average" and you start to get the point.
>The percentage of users that require 2G+ files is much much smaller than the
>Millennium crowd.
This isn't a democracy.
Free software is, generally speaking, a "tyranny of the implementors."
The things that people work on tend to get implemented.
The things that people don't work on definitely don't get implemented.
This is particularly relevant in that we probably *do* have the two
following populations:
a) 10,000 Matrox Millennium users that would like support for the
latest and greatest version of the card, but that contribute nothing
to the effort, and
b) An organization like Sandia Labs (picking a name at random), that
represents a mere 100 users that want Real Big Files, but that is
willing to pay $50,000 for a kernel developer to do the improvement to
ext2.
The net result of this scenario:
- Big files get implemented
- The 10,000 users that contributed nothing to the process will whine
resultlessly.
(The fact is that if those 10,000 users tossed $10 apiece "in the
pot," that would provide $100,000 to help hire developers, which would
provide the "economic signalling" to nicely indicate what they want,
but seeing as how they're too cheap to do that, they are likely to
continue to whine gracelessly and be ignored.)
>-The IA-64 won't solve this problem, because there won't be enough
>-software for business users. When I say "business users" I'm not
>-referring to people who want an office suite for the desktop, but
>-rather the data warehouse crowd. The reason that they're even
>-considering Linux is that apps such as Oracle, DB/2, Tuxedo, and such
>-are at last becoming available. I don't want to hear anyone talking
>-about MySQL; it simply doesn't have the horsepower or even the basic
>-features (ever hear of ROLLBACK WORK?) to run this kind of stuff.
>
>Question: Do these applications have the ability to store data in raw
>partitions?
That doesn't solve the problem. The "big file problem" isn't
predicated solely on the filesystem not supporting big files; it is
predicated on "big files" not being supported at several levels that
happen to *include* the filesystem.
Raw partitions don't help when you can only seek 2GB into the
partition.
>-Scientific users -- the folks most people think of when the word
>-"supercomputer" comes up -- may not care as much because they're all
>-running custom stuff anyhow, and they're used to porting stuff at the
>-drop of a hat. But that dog won't hunt in the business world. These
>-guys really do need to handle a lot of data (the more the better as
>-far as they're concerned), and they also need the applications that go
>-along with them.
>-
>-Furthermore, the problem Linux has with large files isn't the OS, but
>-the filesystem. glibc 2.1 doesn't have any problem with large file
>-offsets, but ext2 does, and I suspect that the VFS layer does also.
>
>Not sure about the VFS. ext2 definitely does. That's why whenever this
>discussion comes up, I always ask why does ext2 need be changed to support
>2G+ files? Why not simply come up with another filesystem to support large
>files?
>
>ext2 is very good at what it does the most. Adding 2G+ support will make it
>less good at what it does the most. So why change it?
The problem is that if the VFS layer changes, then ext2 *has* to.
There's a slippery slope here; in order for "big files" to be useful
at the application level, changes pervade other levels.
>-> Unlike some other OSes I could name, Linux doesn't keep its swap-file
>-> stored in the same filesystem as system and user data/apps. This is
>-> the only file that could realistically approach 2GB, and that an
>-> average user could come across. But even that example may be pushing
>-> it.
>-
>-Let's not put up straw men, shall we? Big iron types (at least the
>-ones who know what they're doing) aren't interested in pitiful little
>-NT toys. The right comparison here is against Solaris and AIX, both
>-of which have supported big files for several years now. They do use
>-swap space, but if they're going to go 2 GB deep into it, they're
>-going to have a problem, which is why they're going to have those big
>-machines loaded to the gills with RAM (which is something else Linux
>-needs to fix). Any home user going 2 GB into swap space is likewise
>-going to be hurting badly for performance.
>-
>-2 GB just isn't all that much data these days. We haven't reached the
>-point yet where a single image is 2 GB, but we're within striking
>-distance. And let's not fall into the trap Windows did with its
>-16-bit garbage.
>
>I don't this is the case. There is already 64 bit file offset support in
>the library. The kernel can certainly handle disk arrays in the terabytes.
>The only missing piece of the puzzle is a filesystem that natually supports
>large files. I simply believe that ext2 should not that filesystem.
No, there are *two* missing things:
a) FS that naturally supports large files,
b) Applications that support large files.
--
Rules of the Evil Warlord #10. "I will not include a self-destruct
mechanism unless absolutely necessary. If it is necessary, it will not
be a large red button labelled "Danger: Do Not Push". The big red
button marked "Do Not Push" will instead trigger a spray of bullets on
anyone stupid enough to disregard it. Similarly, the ON/OFF switch
will not clearly be labelled as such."
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Yung-Hsiang Lu)
Subject: syslog vs printk
Date: 14 Jul 1999 00:35:21 GMT
Hi,
Can anyone tell me the major difference between printk and syslog?
When to use printk and when to use syslog? I notice that syslog will
automatically add date / time / host name. Is there a way to get rid
of it?
Thanks lot!
--
Sincerely,
Yung-Hsiang Lu
[EMAIL PROTECTED]
------------------------------
** 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
******************************
