Linux-Development-Sys Digest #224, Volume #6 Wed, 6 Jan 99 03:14:30 EST
Contents:
Re: Linux 2.0.35 - Linux 2.0.36 (Stefaan A Eeckels)
Re: GUI, The Next Generation (Gary Momarison)
Re: Registry for Linux - From the top (was Bad Idea) (Tristan Wibberley)
Re: framegrabber device drivers ("Bjorn Wesen")
Re: Registry for Linux - Bad idea (George MacDonald)
Re: WDM Emulator, anyone? ([EMAIL PROTECTED])
Re: 2.2.0.pre4 fs/ntfs/inode.c compilation failure (Martin Stolle)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Subject: Re: Linux 2.0.35 - Linux 2.0.36
Date: 5 Jan 1999 21:02:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jan H�hne) writes:
> Hello
> I've got a problem!
> I had SuSE-Linux 5.3 with the Kernel-Version 2.0.35 and now had it
> updated on the Kernel-Version 2.0.36! And now on start up the Kernel
> prints: module unable to load, this module is compiled for Kernel 2.035!
> Must must I do to run my system fine????
You should also do a
make modules; make modules_install
to build and install the modules for your new kernel.
Take care,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: Gary Momarison <[EMAIL PROTECTED]>
Subject: Re: GUI, The Next Generation
Date: 05 Jan 1999 14:27:42 -0800
The first GUI thing I want, which I haven't seen since my VT-100 of
20 years ago, is a text window that scrolls smoothly enough to read
while it's scrolling. An adjustable scroll speed would be nice too.
Here's the rest of my dream GUI:
(This wouldn't be all that hard to do. Some of it just using
existing WMs. Maybe some day...)
About an inch of the right side of the screen devoted to small monitor
displays (date, time, mail, loads, etc.), and a few buttons (desktops,
most used apps, and last few visited windows (m1 raise, m2 (de)iconize,
m3 lower)). This part of the screen floats on top unless you turn that
off. The rest of the screen is devoted to app windows. I usually want
one big one for one app at a time and need a good way to switch them.
The "new" feature is a key (or foot tap) that instantly changes the
screen to a full-screen "navigation" display that has menus and/or
icons and/or buttons for choosing which window or app (running or not)
you want to now be "current", with the pointer active within it.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - From the top (was Bad Idea)
Date: Tue, 05 Jan 1999 22:31:17 +0000
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> >
> > > Can we please take this from the top?
> >
> > *VERY* good idea. I will join in and help.
>
> Let's. I'm going to try to change the subject to this thread. I sure hope
> dejanews does not puke on it this time...
No, just start a new one "config library" in
comp.os.linux.development.apps.
Note the newsgroup: comp.os.linux.development.apps!
The best projects evolve, so go for the library, for apps only. Expand
the design later.
Soon after, we will need a mailing list.
Don't reply to this message, lets stop this thread and start again right
now.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: "Bjorn Wesen" <[EMAIL PROTECTED]>
Subject: Re: framegrabber device drivers
Date: Wed, 6 Jan 1999 00:15:54 +0100
Robert Kaiser wrote in message <76q6si$fvs$[EMAIL PROTECTED]>...
>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
The hardware has scatter/gather DMA, and the Linux port it runs on has no
memory protection so letting the device pump data directly into the user
buffer is certainly possible and easy - however it would cause severe queing
if requests need to be served faster than the hardware can grab. In those
cases an internal buffer would be more optimal for latency at least.
Perhaps two modes of operation would be the best solution then - as long as
requests come in a sane rate, the driver would just DMA a new grab directly
to the user, and if requests come faster, it would start buffering pictures,
perhaps using a buffer allocated from the kernel when booting (like in
bigphysarea).
One complication might be that if the user has allocated a buffer smaller
than the picture size, and performs two reads, then you can't use
scatter/gather DMA directly from the framegrabber, because the two reads
would read two halves of two different pictures :) that would need to be
detected then and fallback to the caching approach, saving that picture for
later, and if the user waits too long, he'd just get a read error because
the cache memory needed to be used.
>Hope this helps
>
>Rob
Thanks for the suggestions,
/Bjorn
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Wed, 06 Jan 1999 07:28:25 GMT
Frank Sweetser wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > > hrm... okay. so this would then require 1) some way of logically combining
> > > multiple files in to a single 'virtual' config, and 2) locking the entire
> > > group, making sure that there are no files shared between that group and
> > > any other groups that are locked... could be hairy with files, should be
> > > easier with databases, no idea about CORBA :P
> > >
> >
> > Could create a new hierarchy with just the changes. Then push the changes
> > in the front of a path of configs to merge together. Then only have to worry
> > about someone else creating another branch at the same time. Could
> > allow either locking or open changes with a merge done automatically
> > and user notified on conflicts(or let latest save win a conflict).
> >
> > This is the stuff of DB table/row locking and commit/rollbacks. All
> > of which can be done in a fs using cow, lockfiles, ... The biggy
> > is having at least one kind of atomic operation i.e mv or rename.
> > Of course it's way slower on a fs, but we are talking user speeds
> > for the most part. If the need is really there, i.e large systems/
> > networks or many config changes then use a DB &/CORBA.
>
> that works. inefficient on FS stuff, but if you need effeciency you should
> be running it on a DB (or something similar) anyways.
>
> > > hmm... so, are you suggesting that in addition to the config data, certain
> > > components would also contain code for configuring that code? <hmm...> if
> > > the library could deal with raw binary data, then it could be treated as
> > > just another configuration entry.
> >
> > It doesn't have to be binary data, all binary data can be represented as
> > ASCII. Remember one of the goals is to make the config info
> > understandable to users. I am thinking the data can be typed or
> > more appropriately "classed". i.e. the config files contain chunks
> > of persistent config objects.
> >
> > Lets say one of the attributes is a color, then it would be nice to
> > have a color selector component that could be used when a user
> > decides to set a color preference. It would be one less thing for
> > developers to develop again and again. In fact I think GNOME
> > has something like this.
>
> herm.... okay, i think i've got you. an independant program associated
> with the value, right?
Or a component, i.e. a color selection dialog that is dynamically linked
into the app when needed. In CORBA language -> activate the component
on demand.
> so rather than storing the actual exe in base64 as
> a perl script, simply store the name of a local exe (which also solves the
> problem of having one that works on different platforms). have i got you
> right?
I believe so. I think we are talking about two things. One is the
evaluation of the color attribute in a config file the other is the
user setting the colol interactively, or more correctly what
tool/component to they use to set the value of a variable of
type/class color.
The first is the equivalent of value=`cat /tmp/lastColors | grep myColor`
or something similar. i.e. value is determined by running the
commands out to the shell and setting the value based on what the
output of the commands are.
Actually I was also thinking the resource file could be marked
executable, and then the contents could be
#!/bin/sh
#
#
C1=`cat /tmp/lastColors | grep myColor`
echo "MyColor="$C1
Or something similar. Then any language could be used to create an output
stream of config info, perl, python, sh, awk ... take your pick. Your
idea follows on from that, i.e. we could have a "shellout" character
that causes the field to be evaluated using the rest of the line as a shell
command. Perhaps using the shell's backtics, or awk's system() or |"cmd"
When to do the evaluation is an issue, CB mentioned it earlier.
Actually just adding this capability to X resource files would do
90% of what I'm looking for!
Well I still want to be able to update from a running app.
Anyhow these mechanisms as well as others could be arbitrarily
complex if we make the file input side module based, i.e.
a X resource module, a gnome module, a KDE module. Each
module could know how to read/write to the required format.
The other part of what I was talking about is more for component based
apps. i.e. it could be possible to write one config component that
just works on the known class/types of config information for
that app. Note this assumes sufficient info is available to
describe the config types/values for an app. This approach
would be similar to defining a MIB per application, or perhaps
generating one automatically(which should be possible for GNOME/KDE).
In other words it might be possible for a developer just to
write the code and completely automate the config editing/setting
mechanism. Imagine not having to write preference dialogs ...
Actually X makes an attempt at this with something called
resEdit, which allows you to edit a running applications
X resources. The only problem is that it's external to the
app, and it does not save the resources in a manner that the app can
use on restart. It's also not a very stylish interface.
All of these are minor problems, the basic mechanism could
be adopted and nicer components used in GNOME/KDE. In fact
they may already be doing this.
The thing that's missing from X, and probably also the
thing that would stop GNOME/KDE from doing such a thing,
is not having a type/class to know what are legal values
for a config variable. Also there is no textual description
nor any mechanism to allow help info. These things are
defined in MIB's, thus you can browse a SNMP network
device asking each object what type it is, and also
what does the value do. This additional information,
called "Meta Data", provides for extra processing
capabilities. It's kind of hard to understand
without seeing it in action. The real value of
meta data is that it would allow tools other
than the application, to peruse and manipulate
config info in a meaningful way.
For example a system admin could write a script to
go through all users config's looking for a
company phone "object" and process it. For
example, let's say every user at a company has
a fast dial number (i.e. a 3 digit number
to reach anyone in the company). Let's also
say that they all have apps that use these
objects and store them in config files.
Now let's say the company is growing and
needs to convert to a 4 digit numbering
scheme, for the moment everyone will
start with a new 3 in the front.
If the config info is classed, then
the script could look for all local
phone objects and simply add a 3 to the front of
the number atribute of the object. I other words everyones
configs could be changed by a very simple script. Well it's
a bit of a contrived example, but can you imagine
doing the same thing with untyped flat files?
>
> > > > to put togther a feature list ... See
> > > >
> > > > http://at.home/gmd/opStore/
> > >
> > > this web site doesn't seem to be up ATM.... :(
> >
> > Oops should be
> >
> > http://24.1.97.22/gmd/opStore/
>
> aha, i see what happened - i tried http://24.1.97.22/gmd/opStore which in
> turn gives a 301 permenantly moved to http://at.home/gmd/opStore/ which in
> turn doesn't work.
>
> read it over, looks pretty good to me. suggest the next steps are to start
> defining 1) data types 2) the library API 3) the config module API and 4)
> the flat text file format.
>
> > > > http://24.1.97.22/gmd/tps/treepsfm.html
> > >
> > > and neither is this one :(
> >
> > Hmm, that one should be. Could you try again and let me know? I check the
> > log and got some hits today and the server seems ok just now.
>
> works now... must have mistyped it earlier =(
>
> > Are you familiar with X resources? How about ini file formats?
> > I am much more familiar with X resources than ini file format,
> > and realize they are not the easiest to understand.
>
> not really... mind explaining it? =)
Many X applications(most until recently) use widget toolkits
to build the GUI. These are psuedo objects, i.e. they have
many of the properties one would expect in an Object Oriented
system. In any case they have attributes that define how
each widget looks(i.e. it's color, size, fonts used ...).
In X these are called resources and they can be set externally
in a X resource file, or by using other means. In any case,
each X based application has a top level widget, every other
widget is added to it, or to one of it's children. This
forms a tree of widgets. So X resource files comprise
of setting resources by using a path through the tree
to the widget that you want to set a value on.
i.e.
topLevel.myTreeWidget.background: green
would set the background of myTreeWidget to green. From
this I can also tell that myTreeWidget is a child
of the topLevel widget. Well that's nice, but things
get more complicated. You can use Class names as
opposed to instance names i.e.
Button.background: black
Sets the value of all widgets of type/class Button to
black. Even if they are 12 levels deep in the tree.
Also you can widcard to skip any number of levels.
i.e.
topLevel*button.foreground: white
sets the foreground of any widget "named" button that
is somewhere under the top level.
These mechanisms are very powerful and allow one
to set values with the minimum of entries in
a X resource file. In other words the minimum
of typing! The problem is that it's kinda
hard to figure this out if you arn't a Comp
Sci person who does recursive tree algorithms
during coffee breaks for fun. Have a look
in
/usr/X11R6/lib/X11/app-defaults
and you will find a whole bunch of X resource files.
Also X resources can have defaults specified in a app-defaults
file, and then these can be overriden by the user. Several
mechanism are provided to do this, and these mechanism
all handle language localization issues. Again this
is very powerful. The big problem with these
mechanisms is that they are not very accessable for
general users. i.e. you have to understand a lot
about the X model, X resources and even comp sci
just to set the background color of an application.
Worst of all is the fact that there is no defined mechanism
to write to the resource files to make run time changes.
One of the aproaches we could take would be to use
the X resources as the file format for config info.
This probably isn't practical, so I would suggest we
develop a plugable architecture, and later create
a plug in module that can read/write X resource files.
This could be used for apps that want to keep X resource
files as their storage format.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Tue, 05 Jan 1999 22:34:15 GMT
Hi,
This may be of some interest for you -
http://www.krftech.com/windrv/linux.html
mlw <[EMAIL PROTECTED]> wrote:
> I want to write a WDM emulator for Linux.
--
PA
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Martin Stolle <[EMAIL PROTECTED]>
Subject: Re: 2.2.0.pre4 fs/ntfs/inode.c compilation failure
Date: Tue, 5 Jan 1999 08:24:31 +0100
Hello,
On 4 Jan 1999, N1ho wrote:
> inode.c: In function `ntfs_decompress_run':
> inode.c:421: `ntfs_s16' undeclared (first use this function)
> inode.c:421: (Each undeclared identifier is reported only once
> inode.c:421: for each function it appears in.)
> inode.c:423: `ntfs_s32' undeclared (first use this function)
> make[3]: *** [inode.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.2.0/fs/ntfs'
> make[2]: *** [first_rule] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.2.0/fs/ntfs'
> make[1]: *** [_subdir_ntfs] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.2.0/fs'
> make: *** [_dir_fs] Error 2
>
> Note that this is a manual transcription, but I believe it's all there and
> correct.
> I took a quick look at the code, and didn't see any obvious syntax errors, so
> it looks like some value didn't get picked up somehow, but I don't know where.
>
> BTW, 'make xconfig' was fixed (compared to what I saw in 'pre2') and apparently
> the menu has grown like a St. Bernard puppy.
> ------
> If you send me spam (except for Hormel products), be aware that I'll simply
> forward
> it to [EMAIL PROTECTED] and let AOL's legal team handle it as they see fit.
>
>
I got the same problem.
I backed up the file /usr/src/linux/include/linux/ntfs_fs_i.h to
ntfs_fs_i.h.old, and added to it
typedef unsigned char ntfs_u8;
typedef unsigned short ntfs_u16;
typedef unsigned int ntfs_u32;
typedef unsigned long long ntfs_u64;
the following lines:
typedef signed char ntfs_s8;
typedef signed short ntfs_s16;
typedef signed int ntfs_s32;
typedef signed long long ntfs_s64;
and the compilation succeeded.
Because this is my private patch, and not official, if you want to do
the same, don't forget to copy back the original file before next patch.
Greetings,
Martin Stolle
***************************************************************************
* Dipl. Inform. Martin Stolle * * * *
*************************************************** *** *** *
* KIV in Hessen * Privat: * ***** ***** *
* Bartningstrasse 51 * Kirchbergstrasse 8 * ******* ******* *
* 64289 Darmstadt * 64625 Bensheim * *
* Tel. +49/6151/704-536 * Tel. +49/6251/680497 * ******* K K I V V *
* Fax +49/6151/781354 * Fax +49/6251/680479 * ***** KK I V V *
*************************************************** *** K K I V *
* E-Mail: [EMAIL PROTECTED] * * *
* [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
******************************
