Linux-Development-Sys Digest #211, Volume #6 Mon, 4 Jan 99 11:17:58 EST
Contents:
Re: ppp-compress-xx problem in 2.2.0-pre4 (Paul Flinders)
Re: 2 stacks? (Stephen Lee - Post replies please)
Re: Something Simple? (Stephen Lee - Post replies please)
Re: Registry for Linux - Bad idea (Andrew Morton)
Re: silly question (Stephen Lee - Post replies please)
Re: framegrabber device drivers (Robert Kaiser)
Re: help with trakker QIC-80 tape drive connected at printer port ("Network
Administrator")
Re: GUI, The Next Generation (Dale Pontius)
Re: 2 stacks? (Andrew Morton)
Re: Registry for Linux - Bad idea ("David Sugar")
Re: Registry for Linux -> Use CORBA!!! (Andrew Morton)
Re: Registry - Already easily doable, in part. (Andrew Morton)
Re: Matrox Millenium G-200 Drivers (Evan Greenberg)
Re: Registry for Linux - Why? (Andrew Morton)
Re: Registry for Linux - Why? (Andrew Morton)
Re: Registry for Linux - Bad idea (Robert Krawitz)
Re: Registry for Linux - Bad idea (Robert Krawitz)
What does "set_fs( )" and "get_fs( )" ? ("J. A")
----------------------------------------------------------------------------
From: Paul Flinders <[EMAIL PROTECTED]>
Subject: Re: ppp-compress-xx problem in 2.2.0-pre4
Date: 04 Jan 1999 11:20:47 +0000
Steven Hand <[EMAIL PROTECTED]> writes:
> David Ronis <[EMAIL PROTECTED]> writes:
>
> > I've just finished installing 2.2.0-pre4 on an i486. It runs, however
> > I've been getting the following error(?) reported in my messages file:
> >
> > modprobe: can't locate module ppp-compress-21
> > modprobe: can't locate module ppp-compress-26
> > modprobe: can't locate module ppp-compress-24
>
> You need to add the following lines to /etc/conf.modules (or /etc/modules.conf)
>
> alias ppp-compress-21 bsd_comp
> alias ppp-compress-24 ppp_deflate
> alias ppp-compress-26 ppp_deflate
>
> HTH,
>
> S.
PPP looks for a module called ppp-compress<CCP Option>, 24 is MVRCA
(Magnalink) - described briefly in RFC1975 so it should probably be
alias ppp-compress-24 off
The full list of ccp options is
0 OUI [RFC1962]
1 Predictor type 1 [RFC1962]
2 Predictor type 2 [RFC1962]
3 Puddle Jumper [RFC1962]
4-15 unassigned
16 Hewlett-Packard PPC [RFC1962]
17 Stac Electronics LZS [RFC1974]
18 Microsoft PPC [RFC2118]
19 Gandalf FZA [RFC1962]
20 V.42bis compression [RFC1962]
21 BSD Compress [RFC1977]
22 unassigned
23 LZS-DCP [RFC1967]
24 MVRCA (Magnalink) [RFC1975]
25 DCE [RFC1976]
26 Deflate [RFC1979]
27-254 unassigned
255 Reserved [RFC1962]
See ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers
------------------------------
From: Stephen Lee - Post replies please <[EMAIL PROTECTED]>
Subject: Re: 2 stacks?
Date: 4 Jan 1999 11:16:53 GMT
In article <769kbp$abf$[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>On 26 Dec 1998 13:41:31 GMT, jan david mol <[EMAIL PROTECTED]> wrote:
>>Just an idea thrown into the world:
>>
>>Would it be worth while to split our traditional stack into 2 stacks,
>>one to hold local variables/parameters and the other to hold return
>>addresses.
>
>The downside is that the system then has to treat an additional register
>as a stack register, thus reducing the number of registers available to
>be used for other purposes.
How about making the stack grow forward instead of backward, that way you
can only overflow into unused stack memory rather than the return address...
It'll need to be placed far away to make growing room for the heap, but I
assume this will not hurt a lot of applications.
Stephen
------------------------------
From: Stephen Lee - Post replies please <[EMAIL PROTECTED]>
Subject: Re: Something Simple?
Date: 4 Jan 1999 11:27:57 GMT
In article <[EMAIL PROTECTED]>,
David D. Gitchell <[EMAIL PROTECTED]> wrote:
>Here's a simple program to display the sizes of each of the elements of
>the stat structure, followed by the results of its execution:
>
<pedantic>
>void main() {
main() returns int.
> printf("Sizes of 'struct stat' elements:\n");
> printf("st_dev: \t%d\n",sizeof(dev_t));
sizeof returns an unsigned type so %d is definitely not correct. Since you
do not know the size of size_t you should typecast here. The type te
typecast to is left as an exercise to the reader...
</pedantic>
Stephen
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 04 Jan 1999 23:29:24 +1100
Nix wrote:
>
> Michal Mosiewicz <[EMAIL PROTECTED]> writes:
>
> > By registry, I mean:
> > a) an easily accessible database with optimised indexed storage
> > b) kernel space managment to accomplish ownership of database records
> > and access rights (not only per user, but also per application)
> > c) events/notifiers/signals to allow for asynchronous notification about
> > the changes in the state of variables
>
> This exists. It is called `the filesystem'. The indexes are unusual,
> but this is a hierarchical database after all, not a relational one.
>
> Yes, /etc *is* a registry; fairly free-format, but still a registry of
> sorts.
But you skipped point c). Big skip, that.
The Unix model of:
- Every app has its own config file
- Every app has its own code to read that file
- Every app needs a restart when something changes (or SIGHUP: almost
the same thing)
- Config is local to this host
is _extremely_ dated, unwieldy, unscalable and expensive. It's
unreliable and requires excessive administration and training resources.
All of the above squared as the era of mobile computing dawns.
I think that was more than my $0.02 worth,
Andrew.
------------------------------
From: Stephen Lee - Post replies please <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: 4 Jan 1999 11:34:16 GMT
In article <[EMAIL PROTECTED]>,
mlw <[EMAIL PROTECTED]> wrote:
>
>Actually, I would love to see Xcopy on Linux. "xcopy /s /e /h /c this
>there" would be great.
How about "cp -a"?
Stephen
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: framegrabber device drivers
Date: 4 Jan 1999 10:58:26 GMT
In article <76m376$o9b$[EMAIL PROTECTED]>,
"Bjorn Wesen" <[EMAIL PROTECTED]> writes:
> Hi, I'm writing a device driver for a quite fast framegrabber and I was
> wondering how to make it scalable regarding device access frequency. I want
> it to handle the load if requests come closer together than the maximum grab
> speed - then the requests should get the same picture. Would it be
> worthwhile to make it a block device and let the page-cache cache blocks,
> and deal with invalidation problems, or should I just let the driver cache
> the latest picture internally and make it a char device (pictures can be
> pretty large!)?
>
> I assume the block device approach would be slower in some situations,
> because there would be one extra copy (to the cache/from the cache to user)
> instead of from the driver to the user directly, if I'm not mistaken.
>
Another possibility would be to DMA directly into user space (assuming
that's where you want the data to end up). That way you don't need
any cache buffer and throughput is close to optimal (I achieved about
50 MB/second with an ITI framgrabber. It has two drawbacks though:
- you have to patch the kernel (see ftp://ftp.sysgo.de/pub/Linux/)
- your hardware must be capable of scatter/gather DMA
Contact me by email (note: return address invalid, see footer) if
you need help about the above mentioned patch.
Another interesting possibility would be Matt Walsh's ``bigphysarea''
patch, which comes with the Matrox Meteor driver AFAIK (sorry,
no URL handy, try dejanews). It also requires the kernel to be
patched, but you may be able to get away without scatter/gather
DMA. On the other hand, you have to pre-allocate your DMA memory
at boot time and that memory is then exclusively dedicated to the
frame grabber.
Hope this helps
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: "Network Administrator" <[EMAIL PROTECTED]>
Subject: Re: help with trakker QIC-80 tape drive connected at printer port
Date: Mon, 4 Jan 1999 08:22:30 -0500
Take a look at ftape. I recently got an Iomega 2GB parallel port drive
working on a Slakware system (kernel 2.0.27). The ftape package supports
trakker drives.
ftape - The Linux Floppy Tape Project
ftape home page, ftape: the Linux Floppy Tape Project
http://www-math.math.rwth-aachen.de/
Curt
guenter weissenseel wrote in message <76h0ap$ij5$[EMAIL PROTECTED]>...
>Hi
>I use Caldera 1.3 Kernel version 2.0.35
>
>Is there a module for the trakker tape backup available?
>It is an external device, whichoperates through the printer port and uses
>standard QIC-80 tapes.
>
>Thanks for any help
>
>Guenter
>
>
------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Subject: Re: GUI, The Next Generation
Date: 4 Jan 1999 13:25:26 GMT
In article <[EMAIL PROTECTED]>,
Ewing James <[EMAIL PROTECTED]> writes:
>
> How about a VR interface designed for shutter glasses or 3D displays and a
> fingertip stylus that allows 'touch and move' instead of point and click?
>
Because sometimes I want to glance at my computer, not pause to get
dressed in it before I can interact with it.
That aside, I agree that there is something that can be done. The
fact that 3D hardware has been here on garden-variety machines for
about a year, leading edge machines longer than that, and NOTHING
has been even prototyped, speaks to the bad effects of Microsoft
on innovation in computing.
Dale Pontius
(NOT speaking for IBM)
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Subject: Re: 2 stacks?
Date: Tue, 05 Jan 1999 00:25:37 +1100
marian wrote:
>
> jan david mol wrote:
>
> > Just an idea thrown into the world:
> >
> > Would it be worth while to split our traditional stack into 2 stacks,
> > one to hold local variables/parameters and the other to hold return
> > addresses. That way, if a program screws up its local variables it cant
> > touch its calling stack (well less easy anyway), thus preserving
> > back-trace info which could get screwed up along otherwise.
> >
> > I'm not sure if this is one for the GCC compiler guys or the kernel ones..
> >
> > Of course if this is stuff which has to be implemented at kernel level it
> > would mean a slowdown in context-switches.. but a kernel compile option
> > could take care of that.. like it does with the profiling support. Maybe
> > problems could be at assembler level, for the CPU's I know only support
> > one stack natively.
> >
> > Anyway, I know MY debugging sessions would be a hell of a lot easier when
> > the bugs don't mess up back-trace, and rewriting the headers/footers of a
> > zillion functions to use a separate memory block for local variables isn't
> > something one wants to waste time on.
> >
> > --
> > Tsjauw,
> > Jan David
>
> There is a nice patch for gcc that puts flags around the return address part
> of the stack. All you do is recompile and it secures your app.
Wow. BDS C had separate data & return stacks, but that was before all
you folks were born :-)
Preferable solutions:
1: Never use strcpy() or sprintf(). Start a campaign to stamp these
damn things out.
2: class String;
------------------------------
From: "David Sugar" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 4 Jan 1999 07:24:33 -0500
[EMAIL PROTECTED] wrote in message
<76ot2o$hmo$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On 03 Jan 1999 12:40:46 -0500, Frank Sweetser <[EMAIL PROTECTED]>
posted:
>> >[EMAIL PROTECTED] (Christopher B. Browne) writes:
>> >
>> >> There would be merit to having a highly robust, *CONVENIENT TO USE*
library
>> >> called, oh, say, libconfig.so, that provided, within a small amount of
code,
>> >> some useful configuration functionality.
>
>A library called "libconfig" exists. It is a .ini-file clone. I have looked
>around a little and the library I find most promising is "libPropList". It
is
>distributed together with the window manager "Window Maker", so chance is
you
>already have it. What I would like to use would be a X Resource Manager
clone
>that does not require X, but with a few features Xrm lacks.
Actually, having a 'standard' shared library with a 'known' interface that
is commonly used would be extremely useful. One could then substitute
alternate libraries to read config info from a central database, through
ldap, etc.
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: Tue, 05 Jan 1999 00:37:47 +1100
George MacDonald wrote:
>
> [ deletia ]
>
> The architecture I am thinking about is as follows:
>
> ---------------------------------------------
>
> Applications
>
> Library CORBA File System SNMP
> Interface Interface Interface Interface
> | | | |
> | | | |
>
>
> Configuration Services
>
> | | |
> | | |
> Flat files Relational DB OO-DBMS
>
> --------------------------------------------------
>
George, I believe CORBA should be in there from day one. Gnome's ORBit
seems lightning fast - I'd like so see it benchmarked against
open()/parse()/close() of a config file.
Make the architecture:
Client app:
API
|
ORB
|
Local config server: |
ORB
/|\
/ | \
/ | \
/ | \
/ | \
flat DBMS Remote management entity ORB
files
The top-level API would hide the CORBA/file/DBMS/remote manager
details. The ORB's there for apps which need higher functionality such
as notifications, config writeback, etc.
BTW: A lot of what you're proposing seems to be in KDE: system-wide
hierarchical config with per-user overrides, the ability to write back,
etc. Looked at it?
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Tue, 05 Jan 1999 00:50:11 +1100
May I point out some shortcomings of the filesystem-based approaches?
1: They're Linux specific.
2: They're "single system centric" (tm). We need to pay more
recognition to the requirement that reconfiguration of applications is
an enterprise-wide function. The rdist approach is klunky (how do I
simply change/propagate a single line of config?)
3: They do not provide for notifications to running applications.
Let's stop thinking "Linux registry" and start thinking "Unix Active
Directory".
------------------------------
From: Evan Greenberg <[EMAIL PROTECTED]>
Subject: Re: Matrox Millenium G-200 Drivers
Date: Mon, 04 Jan 1999 08:49:39 -0500
Check out:
ftp://ftp.suse.com/pub/suse_update/XSuSE/xmatrox/
What you're really looking for is an X server that supports your
video card.
--Evan
JS wrote:
> As with most people I talk to about Windows (serious users that is), I'm
> pretty frustrated with crashes when I want to do anything "out of the
> ordinary" during setups. Hence, I've checked into Linux.
>
> I have Red Hat v. 5.1. I would like to run Xwindows but I can't figure out
> how to configure my video card correctly. It is an 8MB Matrox Millenium
> G-200 (AGP bus).
>
> The driver doesn't appear when I'm doing the setup so I tried selecting the
> 'unlisted video card' but this doesn't seem to work.
>
> I would appreciate any help.
>
> Thanks,
>
> Jim
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Subject: Re: Registry for Linux - Why?
Date: Tue, 05 Jan 1999 00:56:57 +1100
Konstantinos Agouros wrote:
>
> [ snip ]
>
> The point with a registry for Unix-Systems is, that it must be editable by
> a texteditor by someone who knows what he or she is doing.
>
But this does not imply that the database format must be ASCII text. It
implies that ASCII import/export applications are required.
------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Subject: Re: Registry for Linux - Why?
Date: Tue, 05 Jan 1999 01:11:37 +1100
George MacDonald wrote:
>
> [ slice ]
>
> Also simply centralizing user config does not solve all the problems,
> i.e. they may want different settings for apps based on the machine
> they are running on. For example different color settings for
> workstations that have different color depth. So again allowing
> arbitrary levels of a hierarchy would allow both centralized
> configs with localized overrides. This would allow users to
> roam to other systems carrying as much config as they want,
> and being able to tune the app to the current platform if
> desired.
I hate to throw this into the mix, but...
The ultimate resolution to this very common problem is to make config
executable. Rather than always having
name=value
you need the option of
name=`code which returns value`
OO config!
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 04 Jan 1999 09:47:29 -0500
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Robert Krawitz <[EMAIL PROTECTED]> wrote:
> > Certainly it is, but it's one more thing that has to be working in
> > order just to get started.
>
> I dont see how this is a valid argument. So it's something extra.
> Why is that "wrong"? What does this have to do with centralizing the
> configuration data? There cant be progress without change.
All other things being more or less equal, the more things that have
to be running in order to boot, the more chances there are for
something to go wrong. If some kind of database server needs to be
running in order just to boot, it's just one more place where
something might break.
Progress (or change) for its own sake doesn't interest me; there has
to be a tangible benefit from the change. In this case it's really
not clear to me what the benefit from this kind of change is. The
claim appears to be ease of use, but I don't understand how something
like this is easier from a user perspective than simply grafting the
appropriate front ends onto the existing configuration files.
The use of text files (and the specific formats of those files) are
well settled technology in the Unix world for maintaining the
information needed by the various programs. The people proposing
these new technologies need to demonstrate not just the benefits of
these new technologies, but why the old technologies cannot be adapted
to serve the desired goals.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 04 Jan 1999 09:52:37 -0500
Frank Sweetser <[EMAIL PROTECTED]> writes:
> i don't know of any such library. however, linuxconf has the same goals.
> it allows for plugins to deal with the various config styles. so, there
> would be a sysV plugin for the /etc/rc.d/ scripts, a sendmail plugin to
> sendmail.cf/aliases/etc, and so forth. it offers, command line, ncurses,
> GTK, and web interfaces - a very nice package, overall, esp once it
> stabilizes a bit.
This is exactly what I mean when I refer to adapting well understood
technology to meeting new requirements. Rather than ripping out
what's good about the current system (text files that can be
understood and fixed by a moderately knowledgeable person, and no
requirement for a database server to be running in order to start the
system), it offers friendly front ends to the existing configuration
files.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: "J. A" <[EMAIL PROTECTED]>
Subject: What does "set_fs( )" and "get_fs( )" ?
Date: Mon, 4 Jan 1999 14:32:53 +0100
I'm wondering if anyone can tell me what the functions "set_fs()" and
"get_fs( )" does?
I am using these functions in a little "device driver" I'm working on, and
they makes it possible to read and write to/from a file on disk. Without
them it doesn't work. So if you know what these functions actually do,
please let me know!
Thanks in advance //
Jimmy
------------------------------
** 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
******************************
