Linux-Development-Sys Digest #852, Volume #6 Mon, 21 Jun 99 02:14:12 EDT
Contents:
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (void)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (Alexander Viro)
Q:gcc function underscores ([EMAIL PROTECTED])
help with SAMBA pwds ("..Luca T..")
PostgreSQL FATAL ? ("Enosh Chang")
Re: TAO: the ultimate OS (Tor Arntsen)
Re: using C++ for linux device drivers (George Farris)
Re: USR OEM Alana DFV PCI V.90 modem (Rob Clark)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (Christopher B.
Browne)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (void)
X apps in C++ (Chad Zalkin)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (Alexander Viro)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (void)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (Christopher B.
Browne)
Re: using C++ for linux device drivers (Andi Kleen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Date: 20 Jun 1999 23:47:06 GMT
On Sun, 20 Jun 1999 22:26:37 GMT, Christopher B. Browne
<[EMAIL PROTECTED]> wrote:
>
>It is quite possible that [NFS and SMB] are flawed due to UNIX-related issues,
>but it is more demonstrable that they have problems that result from
>having been designed with a need to interoperate with MS-DOS, PC-DOS, and
>other variants of the CP/M "clone."
Hmm, are you sure? It seems to me that a lot of NFS' problems stem from
its minimal design. Unix file semantics are complicated; NFS simply
ignores a lot of them. Or are you suggesting that it does so in order
to work well with DOS and friends?
>It would be Really Neat to have something like what the Reiserfs folk
>are working on where the library would provide a clear isomorphism
>between the "record services API" and the "record services" that the
>OS natively supports. That way you take advantage of the FS services,
>rather than hiding from them.
I'm not sure what you mean here, could you please elaborate a little?
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Date: 20 Jun 1999 20:17:27 -0400
In article <[EMAIL PROTECTED]>,
void <[EMAIL PROTECTED]> wrote:
>Hmm, are you sure? It seems to me that a lot of NFS' problems stem from
>its minimal design. Unix file semantics are complicated; NFS simply
>ignores a lot of them. Or are you suggesting that it does so in order
>to work well with DOS and friends?
At least RFC1094 suggests exactly that. Dumb clients as design goal and
DOS as stated example of such client. Now, Sun had one more target -
their own dickless orkstations, but that gave independent increase of
Ll. DOS suckitude definitely contributed big way.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED]
Subject: Q:gcc function underscores
Date: Sun, 20 Jun 1999 23:24:26 GMT
Hi,
Is there a way to remove the spurious underscores from the compiled
version of a c program? ie sub_program -> sub_program__ or func ->
func_ so there's no name change in the compiled routine.
Specifically I'm trying to link routines compiled under gcc and g77.
There's a command line option to remove the underscores from g77
compiled functions, now I just need the equivalent under gcc.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "..Luca T.." <[EMAIL PROTECTED]>
Subject: help with SAMBA pwds
Date: Mon, 21 Jun 1999 01:46:07 +0200
Hi,
i'm trying to set up a linux server in my office, using SAMBA, to connect 4
windows boxes and to provide them the internet access. I setted up the
smb.conf and also the windows boxes. These ones recognize the server
(because when i shut the server down a message like that appears "unable to
locate a server for the domain ecc. ecc.") but the password seems to be
wrong.
Now i used the same names, the same group of my linux users and i also
synchronized the smb and linux passwords.
I read in some newsgroups that there may be some prblems with the windows
registrers but i really don't know where the problem may be, also because i
made an error installing linux and i started the NIS service without setting
it out without knowing how to disable it and if it may cause problems with
samba.
Thanx
Luca Tamburrano (webmaster)
------------------------------
From: "Enosh Chang" <[EMAIL PROTECTED]>
Subject: PostgreSQL FATAL ?
Date: Mon, 21 Jun 1999 08:09:50 +0800
Hi all:
My environment is Mandrake 6.0. After I installed it, I can see
'postmaster -S -D /var/lib/pgsql' in process manager. When I
typed 'psql template1', I got this message as following:
'FATAL: Cannot open /var/lib/pgsql/pg_database'. But I can't
find pg_database anywhere. How can I do to solve this error?
------------------------------
From: [EMAIL PROTECTED] (Tor Arntsen)
Subject: Re: TAO: the ultimate OS
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Date: Mon, 21 Jun 1999 00:44:29 GMT
In article <7kjpqb$u61$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Stefaan A Eeckels) writes:
>Linux: a port of an existing code base.
As far as userland is concerned, you're basically right. However:
Linux kernel: Written from scratch. Old (and proven) concepts though.
-Tor
------------------------------
From: [EMAIL PROTECTED] (George Farris)
Subject: Re: using C++ for linux device drivers
Date: 20 Jun 1999 22:22:16 GMT
In article <7kjdpj$kia$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Nathan Myers) writes:
> Tristan Wibberley <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] wrote:
>>>
>>> I am working a sound driver for linux (I will probably use OSS).
>
> Please use ALSA.
>
Yes I second that. Please use ALSA. www.alsa-progject.org.
------------------------------
Crossposted-To: comp.os.linux.hardware
Subject: Re: USR OEM Alana DFV PCI V.90 modem
From: [EMAIL PROTECTED] (Rob Clark)
Date: Mon, 21 Jun 1999 01:47:14 GMT
In article <7kjq2r$rms$[EMAIL PROTECTED]>,
cookies <[EMAIL PROTECTED]> wrote:
>Hi, all!
> I got a USR OEM Alana DFV PCI V.90 modem, I didn't find it in the list of
>Winmodem. But I am not sure it will work under Linux 5.2. is there anyone
>who can help me?
The references to "Alana" I find on the web are to two models:
Model 2974, 56L PCI w/voice
Model 2975, 56K PCI w/o voice
both appear to be winmodems. Sorry :(
If you have the FCC registration number that is printed on the modem, I
can add it to the list of Winmodems.
Rob Clark, [EMAIL PROTECTED]
http://www.o2.net/~gromitkc/winmodem.html
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 Jun 1999 02:17:13 GMT
On 20 Jun 1999 23:47:06 GMT, void <[EMAIL PROTECTED]> posted:
>On Sun, 20 Jun 1999 22:26:37 GMT, Christopher B. Browne
><[EMAIL PROTECTED]> wrote:
>>
>>It is quite possible that [NFS and SMB] are flawed due to UNIX-related issues,
>>but it is more demonstrable that they have problems that result from
>>having been designed with a need to interoperate with MS-DOS, PC-DOS, and
>>other variants of the CP/M "clone."
>
>Hmm, are you sure? It seems to me that a lot of NFS' problems stem from
>its minimal design. Unix file semantics are complicated; NFS simply
>ignores a lot of them. Or are you suggesting that it does so in order
>to work well with DOS and friends?
I am indicating the latter, that NFS was designed to provide
compatibility with MS-DOS.
<http://www.faqs.org/rfcs/rfc1094.html> documents the NFS protocol.
It does not explicitly name MS-DOS (which slightly disagrees with
Alexander Viro's comments), but does state:
"The NFS protocol is designed to be portable across different
machines, operating systems, network architectures, and transport
protocols."
The fact that MS-DOS was one of the conscious "lowest common
denominators" is something for which I can't direct you to a clear
reference; the sizable list of PC implementations of NFS listed at
<http://www.rtd.com/pcnfsfaq/SecA.html> provide ample evidence, to my
mind, that support for DOS was considered important back in the '80s
when NFS was standardized.
Note from the NFS RFC that it quite specifically *rejects* the notion
that it is intended to provide system-specific semantics; it may be
the "universally used" UNIX FS, but it is definitely *NOT*
UNIX-specific.
>>It would be Really Neat to have something like what the Reiserfs folk
>>are working on where the library would provide a clear isomorphism
>>between the "record services API" and the "record services" that the
>>OS natively supports. That way you take advantage of the FS services,
>>rather than hiding from them.
>
>I'm not sure what you mean here, could you please elaborate a little?
General idea:
Provide a record-handling system that *is* record-oriented, where each
record "feels" to the filesystem as if it were a "file."
With a logging/journalling FS, the action of changing a record would
amount to writing out a new set of contents for a file. This is a
nicely atomic operation from the FS'es point of view, with all the
"good stuff" that goes along with its treatment as an atomic operation
for the purposes of both FS and OS.
Contrast this with using (say) a DBM file to store the data. (You can
change to B-Trees without loss of generality.) Any transaction
locking that takes place must be managed at the application level by
the application; it is considerably more difficult for the OS to
support the atomicity of updates to random portions of files than it
is to support atomicity of *complete* updates to files.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Date: 21 Jun 1999 03:19:30 GMT
On 20 Jun 1999 23:03:35 -0400, Alexander Viro <[EMAIL PROTECTED]> wrote:
>
>Pretty interesting. SCT proposed something like that on l-k several months
>ago. It makes sense for raw devices, but mixing that with the S-U proper
>is *the* way to deadlocks. Some API for write ordering is badly needed
>and getting it portable between Linux and *BSD would be *very* nice.
I like the sound of that -- I wonder if there's been any cross-camp
discussion of the issue.
I would very much like to see the free unixes collectively become a
preferred platform for database work.
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: Chad Zalkin <[EMAIL PROTECTED]>
Subject: X apps in C++
Date: Mon, 21 Jun 1999 03:09:55 +0000
I am very new to c/c++ and Linux as well. I would like to find a few
web sites about programming X applications with c++.
I have a background in a little c++ in windows, and a lot of JAVA and
VB.
If someone can point out a good web site or refrence that I can use, I
would appreciate it.
Thanks
Chad Zalkin
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Date: 20 Jun 1999 23:03:35 -0400
In article <[EMAIL PROTECTED]>,
void <[EMAIL PROTECTED]> wrote:
[S-U]
>To get to the point, Terry Lambert suggested exporting the dependency
>mechanism to userland in such a way that applications could register
>dependencies themselves, getting the same kinds of transactional
>guarantees that soft updates provides for the filesystem's own
>structures. I never did see a proposed API from Lambert, though that
>doesn't necessarily mean he never published one.
>What do you think of that idea?
Pretty interesting. SCT proposed something like that on l-k several months
ago. It makes sense for raw devices, but mixing that with the S-U proper
is *the* way to deadlocks. Some API for write ordering is badly needed
and getting it portable between Linux and *BSD would be *very* nice.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Date: 21 Jun 1999 02:43:45 GMT
On Mon, 21 Jun 1999 02:17:13 GMT, Christopher B. Browne
<[EMAIL PROTECTED]> wrote:
>
>I am indicating the latter, that NFS was designed to provide
>compatibility with MS-DOS.
Hmm, you and A.V. have convinced me.
>General idea:
>
>Provide a record-handling system that *is* record-oriented, where each
>record "feels" to the filesystem as if it were a "file."
>
>With a logging/journalling FS, the action of changing a record would
>amount to writing out a new set of contents for a file. This is a
>nicely atomic operation from the FS'es point of view, with all the
>"good stuff" that goes along with its treatment as an atomic operation
>for the purposes of both FS and OS.
>
>Contrast this with using (say) a DBM file to store the data. (You can
>change to B-Trees without loss of generality.) Any transaction
>locking that takes place must be managed at the application level by
>the application; it is considerably more difficult for the OS to
>support the atomicity of updates to random portions of files than it
>is to support atomicity of *complete* updates to files.
If I understand you correctly, you may be interested in an idea put
forward by Terry Lambert on the FreeBSD-hackers mailing list. Are you
familiar with soft updates? In short, it is a system for tracking
dependencies between filesystem writes in UFS and ensuring that they go
to disk in the correct order. So, for example, you know that a new
directory entry doesn't get written to disk before the inode it points to.
(Let's not hear the old Linux/FreeBSD flamewar about filesystem
reliability, ok, please? It's boring.)
Previously, UFS provided this guarantee by writing inodes synchronously,
so the motivation for this software was the speed boost available by
doing those writes asynchronously. (There are a couple of other
operations which benefit similarly.)
To get to the point, Terry Lambert suggested exporting the dependency
mechanism to userland in such a way that applications could register
dependencies themselves, getting the same kinds of transactional
guarantees that soft updates provides for the filesystem's own
structures. I never did see a proposed API from Lambert, though that
doesn't necessarily mean he never published one.
What do you think of that idea?
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 Jun 1999 04:58:25 GMT
On 21 Jun 1999 02:43:45 GMT, void <[EMAIL PROTECTED]> posted:
>On Mon, 21 Jun 1999 02:17:13 GMT, Christopher B. Browne
><[EMAIL PROTECTED]> wrote:
>>General idea:
>>
>>Provide a record-handling system that *is* record-oriented, where each
>>record "feels" to the filesystem as if it were a "file."
>>
>>With a logging/journalling FS, the action of changing a record would
>>amount to writing out a new set of contents for a file. This is a
>>nicely atomic operation from the FS'es point of view, with all the
>>"good stuff" that goes along with its treatment as an atomic operation
>>for the purposes of both FS and OS.
>>
>>Contrast this with using (say) a DBM file to store the data. (You can
>>change to B-Trees without loss of generality.) Any transaction
>>locking that takes place must be managed at the application level by
>>the application; it is considerably more difficult for the OS to
>>support the atomicity of updates to random portions of files than it
>>is to support atomicity of *complete* updates to files.
>
>If I understand you correctly, you may be interested in an idea put
>forward by Terry Lambert on the FreeBSD-hackers mailing list. Are you
>familiar with soft updates? In short, it is a system for tracking
>dependencies between filesystem writes in UFS and ensuring that they go
>to disk in the correct order. So, for example, you know that a new
>directory entry doesn't get written to disk before the inode it points to.
>(Let's not hear the old Linux/FreeBSD flamewar about filesystem
>reliability, ok, please? It's boring.)
>
>Previously, UFS provided this guarantee by writing inodes synchronously,
>so the motivation for this software was the speed boost available by
>doing those writes asynchronously. (There are a couple of other
>operations which benefit similarly.)
>
>To get to the point, Terry Lambert suggested exporting the dependency
>mechanism to userland in such a way that applications could register
>dependencies themselves, getting the same kinds of transactional
>guarantees that soft updates provides for the filesystem's own
>structures. I never did see a proposed API from Lambert, though that
>doesn't necessarily mean he never published one.
>
>What do you think of that idea?
I'm less concerned about the reliability side (and agree that leaving
aside the flamewar would be a good thing) and more interested in the
availability of a userland mechanism to get at some subset of FS
functionality.
The problem with having something that will work on Linux and *BSD
(which I *do* agree would be a good thing) is that they have
substantially different "VFS" layers, which is probably the place
where such an API ought to get linked into place.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 20 Jun 1999 22:40:52 +0200
[EMAIL PROTECTED] (Nathan Myers) writes:
>
> >Don't ask on the kernel development mailing list for help, or for anyone
> >to test it, because they won't. C++ in a kernel designed with C in mind
> >is risky because of unexpected behind the scenes behaviour.
>
> Probably the only real problem will be getting Linus to accept necessary
> patches to the headers so that the C++ compiler will read them without
> complaint. Such a request is probably doomed, though not for any rational
> technical reason. The result is that you will need to maintain your own
> set of header patches.
How do you know if you didn't try?
Another problem is testing. Every gcc version change so far has exposed
some problems in the kernel. This includes the inline functions in the headers
which are partly a stress test for compiler inline assembly facility.
Because g++ is a completely different frontend from gcc it is reasonable
to assume to it'll cause some problems. For that you're on your own.
One way around this is to use inline functions and kernel macros only from
C functions with a clean interface to the C++ part (this strategy is needed
for Ada kernel modules). It costs a few cycles though.
I also would limit the C++ to bare bones C++ (no constructors for static
objects, no exceptions, no RTTI - libgcc* looks far too bizarre for a easy
kernel port)
The people with the most experience in C++ kernel work are probably found
on the rtlinux mailing lists.
-Andi (who has writen a Ada95 kernel module)
--
This is like TV. I don't like TV.
------------------------------
** 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
******************************
