Linux-Development-Sys Digest #188, Volume #7 Mon, 13 Sep 99 14:13:58 EDT
Contents:
Re: Linux standards compliance (Mark McDougall)
Re: Linux + C + 2 serial port (Josef Moellers)
Re: acurate timing (James Andrews)
Re: journaling: (was Re: EROS, persistency, ext3fs?) (Theodore Y. Ts'o)
Re: Problems building a cross-compiler (Sasa Ostrouska)
Re: Linux standards compliance (Lee Reynolds)
Re: Porting Motif based software... (Allin Cottrell)
A question about Linux system calls (Lee Reynolds)
Re: journaling: (was Re: EROS, persistency, ext3fs?) (Joseph H Allen)
Linux Unleashed Third Edition book with cds on ebay (Ted)
call function of device driver (Reed Lai)
Re: S3 Trio64V2-DX/GX (775/785) (Karl Heyes)
klogd crashes after dialing isp (quark)
Re: Linux + C + 2 serial port (Josef Moellers)
Re: Figure Out The MS Source Code Yourself (Dave Newton)
Re: Linux standards compliance (Leslie Mikesell)
Re: Richards Stevens died (joeh)
----------------------------------------------------------------------------
From: Mark McDougall <[EMAIL PROTECTED]>
Subject: Re: Linux standards compliance
Date: Mon, 13 Sep 1999 17:23:06 +1000
Nix wrote:
> Tristan Wibberley <[EMAIL PROTECTED]> writes:
> > I am not suggesting that for pay developers are any worse at writing
> > software than volunteers
> I am.
Absolute cobblers!
> When you pay people to do something, you will attract people whose
> primary interest is in that money. Not the code quality.
> And those people will bugger up the code turned out by the rest of us
> (even if just slightly).
> Unlinking (even partially) code quality and remuneration *will*
> compromise code quality. (And does.)
Pure idealist sentimentality. Out here in the evil *real* world, where
heathen programmers actually get paid for writing software, our task is
complicated by many more considerations than your simplistic analysis.
Ever heard of requirements specifications? Detailed design? Coding for
maintainability? My paycheck depends on how well *these* things are
done!
You paint a picture of the saintly "volunteer", slaving away over
his/her keyboard night after night, handcrafting code for the good of
the common people. All very romantic but sadly reality falls far short.
Most write code to suit their own purpose, eg. a driver for some
hardware they own, and subsequently release it to the public. In most
cases the functionality is limited to the bare essentials of the
original author. Only then is it picked up and expanded, patched and
fixed by those who *need* to use it. The code only evolves into a
reasonably robust form after it has passed through a number of hands...
...a lot of those whom I suspect write code for living too!
PS From your email address you're either a student or an academic?!? And
you presume to tell the world about *real* programmers??? ha ha ha!
Regards,
--
| Mark McDougall |
| Engineer |
| Virtual Logic Pty Ltd |
| http://www.vl.com.au |
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Linux + C + 2 serial port
Date: Mon, 13 Sep 1999 08:56:31 +0200
Gert van der Knokke wrote:
> =
> Erol ELISABETH wrote:
> =
> > I write an application that get information from a GPS on a serial Po=
rt
> > /dev/ttyS0
> > the application compute this information and send it to the second
> > serial port
> > /dev/ttyS1
> > my problem is that i can't initialise the port the first time i use m=
y
> > little applicaiton
> > I have to lunch minicom to setup the serial port ??? (4800 8 N 1) th=
e
> > 1st time i boot my system
> > after my appli works fine
> >
> > I want to setup the serial port whith my C prog or someting else whio=
ut
> > lunching minicom
> > please help...
> =
> from teh comand line try:
> =
> stty < /dev/ttySx
> =
> man stty will tell you want you can do with it.
> you can set baudrate and handshaking
> =
> stty clocal speed 4800 < /dev/ttyS0
> =
> will set in/out baudrate at 4800 for serial port /dev/ttyS0 with no
> handshake.
IIRC this will only stay as long as /dev/ttyS0 is open, i.e. until stty
exits. The next open() will find the default parameters.
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the author=B4s personal views only!
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: acurate timing
Date: Fri, 10 Sep 1999 16:17:55 +0000
Is there a good reason why no one has mentioned the "time" command? (I
risk looking incredibly dumb if the time command actually returns
jiffies, but I havent looked that close at it ;-) It seems to give the
execution time of a shell command accurate to one nano second (my maths
might be wrong, but 0.001 micros is one nano, ce n'est pas?). It also
tells you how much of this time was spent with the processor and how
much in I/O wait states. Sounds like what you need, standard on every
unix and linux distribution since the dawn of time, excuse the pun,
James
PS. Jiffies is actually a slang term for condoms in Edinburgh, not that
it has anything to do with this thread :-P. It does however bring a
whole new meaning to the term, "I'll be back in a jiffie".
------------------------------
From: [EMAIL PROTECTED] (Theodore Y. Ts'o)
Subject: Re: journaling: (was Re: EROS, persistency, ext3fs?)
Date: 13 Sep 1999 08:18:20 -0400
Stephen Tweedie recently posted an initial release of his ext2
journaling code. You can find it at
ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/release-0.0.1.tar.gz
while in principal it's relatively straightforward, it's not so simple
as you might first think.
Warning: there is a known bug in this version: if you try to use it as
your root filesystem, it will turn /dev into a socket. It seems to work
ok for other partitions, but I wouldn't recommend it for production
data. As Stephen put it, "I'd tell you to backup your data first, but
your data is precious enough to require backing up, you shouldn't be
using ext3 on it just yet."
(Stephen tried to get journalling on the root partition working in time
to do a live-fire demo at the Linux Kongress, but unfortunately the
resulting carnage found two separate bugs in e2fsck. Both of us spent a
couple of late nights hacking on our laptops in the conference hotel's
bar. :-)
- Ted
------------------------------
From: Sasa Ostrouska <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Problems building a cross-compiler
Date: Mon, 13 Sep 1999 12:09:55 GMT
Thanks to all !
I did it.
Sasa
Sasa Ostrouska wrote:
> I tried also in a separate directory like /usr/src/buildegcs and the
> result is the same.
> I was thinking to try with the glibc-2.1.2 and gcc-2.95.1
>
> Thank you
> Sasa
>
> [EMAIL PROTECTED] wrote:
>
> > Don't build in the source directory.
--
R.C. di Ostrouska Sasa Tel.39-0432-510330 e-mail:
[EMAIL PROTECTED]
Via della Rosta,31 Fax.39-0432-505997
[EMAIL PROTECTED]
33100 UDINE - ITALY Mobile.39-348-2202308 web:
http://users.iol.it/rcostro
------------------------------
From: Lee Reynolds <[EMAIL PROTECTED]>
Subject: Re: Linux standards compliance
Date: Mon, 13 Sep 1999 06:05:03 -0700
>
I'm new here. I don't know anything about UDI although what it is and how
it works is easy to guess. From what I've been able to gather there is a
concern among some that linux does not have any kind of a standardized
device driver interface. This makes it more difficult to distribute a
device driver as only a binary. This is a mixed blessing. On one hand it
encourages vendors to either release specs, or develop code in house for
inclusion in the kernel. This is good because it means that the drivers
tend to be stable and any problems with early revision code will be
identified and corrected. On the other hand there are vendors who are
never going to release specs or code to their products. Some may create
kernel modules for their products, but getting these to work with your
kernel can be problematic. If Linux becomes extremely popular then
vendors are going to be forced by the market itself to release specs or
code. But the lack of device support slows linux's growth creating a
situation that is somewhat like a catch-22. Creating a standard device
driver interface would make it possible for a vendor to supply binary only
drivers where they would be unwilling to supply specs or source. This is
good and bad. Good because it means more support, bad because the quality
of the drivers will vary.
Linux is a great operating system, but the road ahead of it is not without
rocks and potholes. How the linux community and the vendors who support
linux work through these problems is going to determine its long term
viability. Red Hat having an IPO doesn't mean we are out of the woods
yet. For linux to survive it must expand and for it to do that it must
have a larger presence outside the server arena. A standardized driver
interface might help it do that because it encourages companies to
officially support linux, which does get noticed by those sitting on the
fence. I only fear that the quality of the drivers will be less than
great.
Lee
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Porting Motif based software...
Date: Mon, 13 Sep 1999 08:54:17 -0400
Juergen Heinzl wrote:
> My reference regarding Metrolink was not an answer to the "free"
> but the Motif part as yes, lesstiff is free while Metrolink is
> not. Now Metrolink is 2.x and lesstiff is not.
Lesstif has included 2.x libs for quite a while now.
Allin Cottrell.
------------------------------
From: Lee Reynolds <[EMAIL PROTECTED]>
Subject: A question about Linux system calls
Date: Mon, 13 Sep 1999 06:23:37 -0700
I've just started studying unix programming so please excuse my
ignorance. Right now I'm studying the book Advanced Unix Programming.
It was written about 15 years ago and it talks about differences between
BSD and System V. From what I've heard Linux implements features from
both families. I'm curious about how compatible it is with source
created for either one. Is linux more like BSD or Sys V? If someone
could give me a pointer on some docs that describe this aspect of linux
I'd appreciate it.
Lee Reynolds
------------------------------
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: journaling: (was Re: EROS, persistency, ext3fs?)
Date: Mon, 13 Sep 1999 15:00:53 GMT
In article <[EMAIL PROTECTED]>,
Theodore Y. Ts'o <[EMAIL PROTECTED]> wrote:
>Stephen Tweedie recently posted an initial release of his ext2
>journaling code. You can find it at
> ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/release-0.0.1.tar.gz
>while in principal it's relatively straightforward, it's not so simple
>as you might first think.
Neat code! I see that it commits modified data to the log before changing
the filesystem, not as I was suggesting in my post, backups of the
unmodified data (hence 'intent' log). This is better since the log data
will be more recent and you will not lose a commited transaction, which
would be the case with my suggestion. Also it's just as easy (or hard) to
implement :-) Don't ask how I came up with the method in my post- it's the
result of a lot of convoluted research into databases, and I had not yet
made that last intuitive leap. I see the comments about breaking up large
writes into transactions, and dealing with quota and truncate, so there are
some complications.
I wonder how they get away with such small intent logs on other systems.
SCO's web site says that it only needs a 10K log- which leads me to think
that they do not address the page integrity issue.
Incidentally, I tried a bunch of tests on IDE hard drives. When you turn
the power off, they try very hard to complete writing that last sector.
They do not know about blocks (of course), so the last sector written can be
in the middle of a block. They do not use power from the spinning disk, big
capacitors or anything like that- they just depending on the power falling
slowly enough to succeed. In heavily loaded systems or if you just short
the power connector so that it goes out instantly (don't try this at home-
if you short the power out in the wrong order it can fry the drive), they
can indeed fail to complete writing a sector (and it will be give a crc
error on read). In lightly loaded systems, they always seem to succeed in
writing complete sectors.
When you read a damaged sector, it gives the expected read error. It does
not become permamently damaged, however, and rewriting it fixes it (which
only makes sense, since write wouldn't know that it's damaged). Address
marks can also be damaged- linux retries a lot more on reading sectors with
bad address marks for some reason, but writing still repairs them. I
suspect that damaged address marks cause alternate sector assignments to be
made when you write to them (which means you can have only so many damaged
address marks per track), but I don't know for sure, and it may depend on
the drive.
When write ahead caching is enabled on the drive (use the hdparm command),
and if the drive actually supports it, sync will indeed return before the
data has been written to the media (this is easily demontrated by writing
100 sectors scattered all over the disk- the command will return and you
still hear the drive seeking- with write ahead caching off, the commend does
not return immediately).
Write ahead caching seems to be disabled by default on SCSI drives, and in
any case I don't know how it would be turned on (I would guess either a
jumper or a custom non-standard SCSI command). Write ahead caching does
make the system quite a bit faster, so turn it on if you don't care about
logging.
Anyway, the conclusion is that any kind of logging system must deal with the
page integrity issue. Hoefully ext3 flushes the body of the transaction to
the log before flushing the commit mark for the transaction (which hopfully
fits in one sector). I think any other scheme would require checksums.
Also, write ahead caching must be disabled for logging to work properly- the
drive assuredly reorders the writes by using the elevator algorithm, so
there would be no guarentee that the log records were written before the
filesystem was actually modified. There should be a note to this effect in
the documentation. Finally, any program which checks for bad blocks should
try writing to them in an attempt to repair them before marking them as
truly bad. It would be nice if the 'badblocks' man page mentioned this as a
reason for using '-w'.
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: [EMAIL PROTECTED] (Ted)
Subject: Linux Unleashed Third Edition book with cds on ebay
Date: Mon, 13 Sep 1999 15:13:28 GMT
Check it at ebay:
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=163795909
Please remove "NOSPAM" from my address to email me.
------------------------------
From: Reed Lai <[EMAIL PROTECTED]>
Subject: call function of device driver
Date: Mon, 13 Sep 1999 21:42:00 +0800
I write a device drive for linux and export some of its functions to
kernel's symbol table. May I call these functions from my C application
in user space? how to do?
Thanks!
Reed Lai
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: S3 Trio64V2-DX/GX (775/785)
Date: Fri, 10 Sep 1999 19:05:57 +0100
neverovatna ponuda wrote:
> need driver for this
> TX
>
try XFree86-SVGA
karl
------------------------------
From: quark (quark)
Subject: klogd crashes after dialing isp
Date: Mon, 13 Sep 1999 18:27:11 GMT
Hi !
I have a P200 MPP System (2 Processors) with Suse 6.2 installed.
Kernel is 2.2.12 or 2.2.10. With both kernels I have the same problem:
After dialin my ISP over ISDN the klogd crashes.
If I start the klogd to write the messages into an own file
(option -f) it is better, but not perfect.
Anyone an idea?
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Linux + C + 2 serial port
Date: Thu, 09 Sep 1999 14:52:05 +0200
Erol ELISABETH wrote:
[ ... ]
> I want to setup the serial port whith my C prog or someting else whiout=
> lunching minicom
> please help...
You should do this using tcsetattr and friends.
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the author=B4s personal views only!
------------------------------
From: Dave Newton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Figure Out The MS Source Code Yourself
Date: Mon, 13 Sep 1999 16:39:25 GMT
d s f o x @ c o g s c i . u c s d . e d u (David Fox) wrote:
> How does what you expect enter into this?
>From a legal standpoint, obviously it doesn't.
> Putting a law on the books means that whenever someone takes a fancy
> to putting you in jail for breaking it, they probably will.
As I said.
> What you "expect" is of little importance.
To you and the law, perhaps, but not to me.
It's simple-I expect common sense to prevail. If I want to reverse
engineer something and play with it I expect people to leave me alone;
I'm not hurting anyone. If someone wants to put me in jail for that,
fine, they can try. I will be civilly disobediant, and if that doesn't
work, I'll be noisy about it.
It's my hardware, I have the right to determine what is running on it.
If someone was painting my rooms I'd expect to be able to find out that
the stuff in the paint wasn't going to kill me.
Dave
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: Linux standards compliance
Date: 13 Sep 1999 11:55:12 -0500
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> wrote:
>Tristan Wibberley <[EMAIL PROTECTED]> writes:
>
>> I am not suggesting that for pay developers are any worse at writing
>> software than volunteers
>
>I am.
>
>When you pay people to do something, you will attract people whose
>primary interest is in that money. Not the code quality.
>
>And those people will bugger up the code turned out by the rest of us
>(even if just slightly).
>
>Unlinking (even partially) code quality and remuneration *will*
>compromise code quality. (And does.)
When do you think airport control systems and hospital equipment
will start using software written by volunteers with public
beta testing so we can have this high quality where it counts?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: joeh <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: Richards Stevens died
Date: Mon, 13 Sep 1999 13:55:01 -0400
Richard wrote:
>
> According to my newsreader, [EMAIL PROTECTED] posted...
> //
> // What tragic news. I feel like we should do something in his memory.
>
> From the funeral announcement at www.bigdealclassifieds.com :
>
> <QUOTE>
>
> The family asks that in lieu of flowers, donations be made in
> Richard's name to
>
> Habitat for Humanity
> 2950 E. 22nd Street
> Tucson, AZ 85713
>
> </QUOTE>
>
> I can't personally think of a more fitting way to show our collective
> appreciation for his many good works and generous spirit than to keep
> the folks at HfH very busy processing donations "in Richard's name."
>
> --
> "The road to wisdom? Well it's plain, and simple to express:
> Just err and err and err again, but less and less and less."
> -Piet Hein
>
> Disclaimer: These are simply some of my personal opinions.
> ObURL: http://home.earthlink.net/~huddler
Are there any biographies of Richard on the inet?
I have 2 of his UNIX books, and yet don't know anything about him
--
If possible please cc: response posts to [EMAIL PROTECTED] as I do not always
have
access to a news server; thanks!
Disclaimer: opinions expressed my own and not representative of my
employers
------------------------------
** 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
******************************
