Linux-Development-Sys Digest #191, Volume #6 Wed, 30 Dec 98 07:14:28 EST
Contents:
Re: Linux rs232 communication ports (Kurt Harders)
2.2pre1 installed nfs writes to solaris2.6 still suck? any ideas??? (Doug
McClendon)
ifconfig and do_ioctl (Eitan Rabin)
Re: Arabic & Linux (francois fritz)
Re: Registry for Linux -> Use CORBA!!! (George MacDonald)
Re: Kernel 2.2 (Dimitris Kontopodis)
Re: Registry for Linux - Bad idea (Christopher Browne)
Re: Registry for Linux - Bad idea (Christopher Browne)
Re: Registry - Already easily doable, in part. (Christopher Browne)
Re: net-tools-1.47 inet6.c incomplete type , won't compile (Andreas Schwab)
----------------------------------------------------------------------------
From: Kurt Harders <[EMAIL PROTECTED]>
Subject: Re: Linux rs232 communication ports
Date: Wed, 30 Dec 1998 07:36:55 +0100
Hallo John,
John Whitt wrote:
>
> Does anyone know where I can find some example "C" code for opening a
> serial port under Linux and and reading and writing to the port?
If the Interface is setup correctly (speed, parity...):
fp = fopen("/dev/ttyS0", "a+");
fread(....);
fwrite(....);
fclose(...);
Thats it.
Regards, Kurt.
--
Kurt Harders mailto:[EMAIL PROTECTED]
PiN - Praesenz im Netz GIT mbH mailto:[EMAIL PROTECTED]
WWW: http://www.pinserve.de http://www.pin-produkte.com
------------------------------
From: Doug McClendon <[EMAIL PROTECTED]>
Subject: 2.2pre1 installed nfs writes to solaris2.6 still suck? any ideas???
Date: Wed, 30 Dec 1998 02:22:20 GMT
I'm testing 2.2pre1, and the only minor issues I had were
a) I had to comment out a seemingly pointless #error in tulip.c
to get it to compile
and
b) I couldn't get the latest util-linux to completely build
correctly (specifically, just the ipcs and ipcrm tools) due
to confusion I think between /usr/include/linux/shm.h and
/usr/include/sys/shm.h.
the latter seems to be from my libc5.4.46 from my SuSE5.3 distribution.
Honestly it's been awhile since I've used ipcrm, so I guess I don't
care.
Unfortunately I'm still getting extremely shitty write performance from
the nfs client when mounting a solaris2.6 box
mount -o async,rsize=16384,wsize=16384 -t nfs monsoon:/ /mnt/monsoon
I've played with the -o options to no avail. I mean WTF???
doing a cp of the 50meg linux-source-tarfile from the sunbox to the
linux box takes all of 10 seconds. But the cp from the linux box to
the sun box takes 4 minutes.
What am I missing? Someone help me please, this has got to be some
stupidity on my part, right?
Doug McClendon
[EMAIL PROTECTED]
------------------------------
From: Eitan Rabin <[EMAIL PROTECTED]>
Subject: ifconfig and do_ioctl
Date: Wed, 30 Dec 1998 10:04:14 +0000
Does anybody knows how ifconfig really works.
The device function dev->do_ioctl receives parameter from it, which
parameters and how to use them?
Any help will be welcomed.
Thanks in advance
------------------------------
From: francois fritz <[EMAIL PROTECTED]>
Subject: Re: Arabic & Linux
Date: Wed, 30 Dec 1998 11:03:55 +0100
mkk wrote:
> What are the Indic scripts ? Any example.
Has Indic the same meaning as Indian ?
Have a look to http://www.worldanguage.com, they have samples of several
scripts in many languages, including indians scripts and languages.
--
Francois FRITZ | SG EQTY/FFD/INF
mailto:[EMAIL PROTECTED] | 17, Cours Valmy (Tour SG)
Tel : (33) 01 42 13 49 13 | 92987 Paris La Defense Cdx
Fax : (33) 01 42 13 40 62 | France / Frankreich
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: Wed, 30 Dec 1998 01:59:36 GMT
TenchiKen wrote:
>
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
> >> >How about it then could everyone start putting user config
> >> >files in
> >>
> >> > $HOME/.userStore/applications/${applicationName}
> >>
> >> >or something similar?
> >>
> >> I like that idea. I don't like .userStore as the name though.
> >> I'd prefer the word seperation to be e.g. .user_store
> >> and the name "user store" doesn't seem quite right for the part
> >> of the home directory that is storing configuration information.
> >> I suggest .conf_store or .config.
> >
> >Thanks for the comments.
> >
> >The reason for "userStore" vs. "user_store" is to alert developers
> >to the OO methodolgy. This seems to be the norm in OO based
> >toolkits such as X/Xt/Motif and in *some* of the newer class
> >hierarchies.
> >
> >The reason for the generic name of Store, again it's more of
> >a OO term. Shorter form of -> user persistent storage. While
> >the vast majority is for config information, the space
> >should also be used for other context files, history files
> >work files ... For example gimp is currently using my home
> >directory to store a temp work file! The file is about
> >40 characters in length and makes a real mess of my ls -artl !!!
> >A better place would be:
> >
> > $GOME/.userStore/applications/gimp/current/workFiles
> >
> >or something similar.
> >
> >Having said that a ".config" covers the 90% solution, it is
> >tempting due to it's clarity? Hmm. any one else have an opinion
> >on this?
> >
> >Would you think it confusing to put history files under a .config?
>
> I think the biggest concern I have is, that I think we need to
> move to a system that configuration looks similar, no matter
> what the application. (not neccesairly simple). If you are
> proposing doing this thru CORBA, I think you blow away any
> kind of configuration restoration.
>
> If you were to do this with a filesystem (with interfaces thru
> CORBA and the standard FS), this might work, even tho I think
> CORBA is overkill (and slow).
Those are good points and I agree with most of what you say. I was
thinking that we could define multiple levels of adoption.
i.e.
Level 1 - Use the new dir hierarchy but use app specific config file
format, naming conventions, access mechanisms, ...
Level 2 - Use a standard file format and access library
Level 3 - Provide CORBA interfaces
Perhaps some finer granularity if required. My initial goal is just
to get the files out of $HOME even if they use non-standard formats
and access mechanism. Once a library is developed then developers
could leverage off of that to save some time. This would be a
light weight library that knows how to read/write the file format.
A very simple locking mechanims to keep multiple apps from writing
simultaneously to the config files would be needed. I was thinking
that *after* that point a CORBA implementation could be layered
on top to provide an interface for component based apps that
are also using CORBA(GNOME, KDE, ...). I wouldn't want to make
the use of CORBA manditory for several reasons. As you say it
is slower(well it can be speeded up if implemented smartly),
but I'm more concerned about the amount of knowledge required
by developers before they can use it properly.
One nice thing about CORBA is that it would allow a wrapper
interface to be consistent, while the implementations can
be specific to an application. This will ultimately provide
the one view of configuration information and then a
single tool/component can be written to view/edit it.
My goal is to define a migration path with several steps,
each step being not too difficult for developers and
at the same time providing incremental benefits. In
this manner it will be easy for everyone to start the journey
and in the end we will be where we ultimately want to be.
Configuration restoration is a good point, I just added it
to the list of requirements. I was thinking about allowing
apps to define a "sane" or default set of config info.
This could be used as a fallback if the config info becomes
corrupt/inconsistent/... The sane/default config
would be read only. I was also thinking it would be nice
to have the ability to save named config sets. Then a
user could setup apps based on some kind of work modality.
Perhaps the config library could have a component for
selecting/saving configurations. Then developers could
just add a menu item or command line option to trigger
the component into action.
--
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: Dimitris Kontopodis <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.2
Date: Tue, 29 Dec 1998 16:27:15 +0200
Andre Weinreich wrote:
> I heard that there is a new Kernel ( 2.2 ).
> Now I'm searching for it.
> Who can help me and show me where I can get it on Web ?
Take a look in:
ftp://ftp.kerneli.org/pub/linux/kernel/v2.2/
Dimitris
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 30 Dec 1998 04:19:02 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 29 Dec 1998 05:38:18 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
>Christopher B. Browne wrote:
>> On Tue, 22 Dec 1998 12:52:33 -0800, [EMAIL PROTECTED]
>> <[EMAIL PROTECTED]> posted:
>> >On Tue, 22 Dec 1998 01:59:27 +0100, Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
>> >>Richard RUDEK wrote:
>> >>> [...]
>> >>> I agree, a registry for linux is a bad idea. But I don't see how a standard
>> >>> configuration procedure "naturally suggests a single file".
>> >>
>> >>Why is it a bad idea?
>> >>
>> >>Or, let me put it this way - what is better than a single database
>> >>optimised for persistent configuration storage?
>> >
>> > A REAL database with transactions, rollback logs, real
>> > schemas, SQL92 compliance, an odbc/jdbc driver interface
>> > and automated disaster recovery.
>>
>> Ah. So one that consumes many megabytes of disk, potentially of memory
>> for the server, perhaps some for each connection, and which is bloated
>> for the purpose.
>>
>> "Real" databases are cool and all, but not for the purpose of managing
>> system configuration.
>
>In a large scale network with very dynamic configuration needs the
>flexibility and power that a database offers is worth the expense.
>In a small system with infrequent changes it is a waste of resources,
>it adds uneeded complexity and simply cannot be justified. What we need is
>a solution that can accomodate both.
"Everything should be made as simple as possible, but not simpler."
-- Albert Einstein
You are assuming that there should be one database.
I disagree. I believe that trying to simplify it down to one database
is an oversimplification of systems that are being used to do complex
things.
It may be reasonable to have some mechanisms to view configuration
through a common mechanism; that will nonetheless represent a mechanism
that unifies some disparate components.
>Have a look at the definition for CORBA's
>persistent storage service POS. In that model they decouple the
>storage mechanism from the objects that use it. Thus an object
>can either specify storage type or not, and a storage server
>can can be configured for flat files or OODBMS as is desired
>for that particular machine/server/object. By providing the
>proper level of abstraction you can do both, and do both well.
Note that none of the "libre" ORBs implement the POS.
Note also that relatively few of the commercial ORBs implement it. They
seem to either eschew it, and "keep simple" (ala OAK) or to provide
entirely more sophisticated mechanisms for handling the Transaction
Service.
The rumors that I hear are more supportive of the claim that POS is a
"failed service" that will be replaced by something (hopefully better)
in CORBA 3.
>The current flat file model is simple/robust/elegant and is a
>natural fit for the environment. One day linux may run on mobile
>computers(oops already is) and we want to keep the kernel as
>small and as tight as possible. Also many core services will
>want to be designed in the same manner. There is a great
>deal of good about the current mechanisms, and there is
>no reason for the vast majority of installations to change
>from it.
>
>Having said that, a more sophistacated config management mechanism
>will be useful for component based apps and for high end systems
>and servers. The only way to progress forward is to recognize
>that the current system should be supported in a new config
>system that wraps it in an OO layer while providing new
>capabilities for components and more flexible storage.
Which is to say that there will be:
- Multiple databases, and
- Some views (once you get to the "sophisticated" level of attaching an
ORB or its equivalent) that seek to provide a unified mechanism for
*attaching to* configuration information.
The base system needs the "flat file" model (or something close to it;
see the NeXTStep configuration model as a not unreasonable
alternative...) for some basic stuff.
--
Avoid the Gates of Hell. Use Linux -- Unknown source
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 30 Dec 1998 04:20:36 GMT
Reply-To: [EMAIL PROTECTED]
On 29 Dec 1998 15:18:26 -0700, TenchiKen <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Robert Krawitz <[EMAIL PROTECTED]> wrote:
>>Sure, but what is the compelling advantage of putting (say) the
>>nameserver in the kernel? It means that you need to make a kernel
>>change to fix or otherwise change the name resolution software.
>
>Maybe this is not neccesary. Maybe we should provide some hooks
>for system service applications to interface with chunks of /proc.
>This would allow us to use /proc to set up everthing, and the method
>of saving this information is really up to the user. (ie, it could
>be a script file that does the echo, or a db based registry, or a
>Linux conf configurator.
>
>Best of all, these would all work together.
>
>of course, the hard part is the code ^.^ My skills are not
>up to this task... (yet)...
I don't have a URL handy (I ought to); there has been a port/simulation
of part of the Hurd "translator" that is used to mount processes as if
they were filesystems *to Linux.*
It is *probably* linked in somewhere around
<http://www.fig.org/gord/hurd/hurd.html>.
Gord, whose site that is, was the writer of the Linux-based translator.
--
"Note that if I can get you to `su and say' something just by asking,
you have a very serious security problem on your system and you should
look into it." (By Paul Vixie, vixie-cron 3.0.1 installation notes)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/oshurd.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 30 Dec 1998 04:18:46 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 29 Dec 1998 04:49:06 +0000, Tristan Wibberley
<[EMAIL PROTECTED]> wrote:
>you get the idea, reverse lookups via hosts needs attention too (note
>the invalid hostname character ':' for clarity).
I *think* I get it; as an alternative, would it seem more appropriate to
do something like the following?
# touch :192.168.1.2
# ln :192.168.1.2 chris.brownes.org
# ln chris.brownes.org chris
# ln chris.brownes.org mail
Thus, once the lookup finds something with a filename looking like
':[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\'
it has found an IP address and thus resolved what it was looking for...
I would somewhat approve of the idea of replacing the colon with a
period, with the result that the IP addresses seemingly "disappear" if
you don't include the "-a" option in ls...
Would we want to have anything at all in the files, or just use the
linkages inherent in the directory structure to reference things? I
can't quite decide.
>> # ln router.brownes.org router
>>
>> Note that this results in 3 files containing a total of 35 bytes, plus
>> directory entries for 9 files. It is quite likely that the disk
>> consumption would significantly exceed 130 bytes whether with ext2 or
>> with reiserfs.
>>
>> If we replaced this with entries in some sort of "binary database"
>> system, it is highly unlikely that equivalent functionality would take
>> less space than either of these "natural" UNIX representations unless
>> shortcuts were taken that would substantially reduce overall system
>> robustness.
>
>I think the database behaviour from filesystems is undoubtably the way
>to go, but it needs some careful thought. Most of the routines at
>boottime are simple and standard, and could be compacted easily, still
>allowing for someone to use scripts if they need more complex
>behaviours. It would be interesting to see what could actually be done
>here.
I agree 100% with the thought that best results come from applying some
careful thought to this.
I was suggesting the above as a "for instance" that could certainly be
improved on by the time it would actually be implemented.
--
Avoid the Gates of Hell. Use Linux -- Unknown source
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Andreas Schwab <[EMAIL PROTECTED]>
Subject: Re: net-tools-1.47 inet6.c incomplete type , won't compile
Date: 30 Dec 1998 12:41:35 +0100
Dimitris Kontopodis <[EMAIL PROTECTED]> writes:
|> Sami Tikka wrote:
|>
|> > This is what I did:
|> >
|> > I got the latest glibc (2.0.100 or something), compiled & installed that.
|> > Oh, by the way, to do that I had to upgrade my compiler to egcs
|> > something...
|> >
|> > Then I edited the net-tools makefile so that it no longer takes the
|> > include files from net-toosl's own include dir but uses the includes from
|> > /usr/include. In the later glibc include files there is the necessary IPv6
|> > support already. Apparently the net-tools just doesn't know that yet.Sami
|> > Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/
|>
|> How did you do that?
|> I have installed glibc 2.0.106 on a 2.1.130 kernel (with all the necessary
|> packets like egcs, binutils, etc) but I still cant compile net-tools :lots of
|> "undefined reference to..." errors like:
|> gcc -Llib -o ifconfig ifconfig.o interface.o sockets.o -lnet-tools
|> -L/usr/local/lib
|> /usr/local/lib/libc.so.6: undefined reference to
|> `_dl_sysdep_start@@GLIBC_2.0'
|> /usr/local/lib/libc.so.6: undefined reference to `_r_debug@@GLIBC_2.0'
|> /usr/local/lib/libc.so.6: undefined reference to `_dl_starting_up@@GLIBC_2.0'
See the glibc HOWTO. You have a broken setup.
--
Andreas Schwab "And now for something
[EMAIL PROTECTED] completely different"
[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
******************************
