Linux-Development-Sys Digest #349, Volume #8 Thu, 14 Dec 00 15:13:12 EST
Contents:
timer interrupts (Matthew Impett)
Re: PCMCIA card installation ("family.luff")
Re: Compiling C++ programs with GCC --> no GPL license implications (Mike Stump)
Re: Compiling C++ programs with GCC --> no GPL license implications (Mike Stump)
Re: Compiling C++ programs with GCC --> no GPL license implications (jbs)
Re: Compiling C++ programs with GCC --> no GPL license implications (Pete Becker)
Re: Does kernel 2.2.18 need to be patched for raid??? ([EMAIL PROTECTED])
Re: Linux GUI programming (Joseph Virzi)
Re: timer interrupts (Kaz Kylheku)
Re: Kernel won't mount raid0 ([EMAIL PROTECTED])
Re: changing BASH's path searching ("Peter T. Breuer")
Re: Problems of DHCP setting (Dave Platt)
----------------------------------------------------------------------------
From: Matthew Impett <[EMAIL PROTECTED]>
Subject: timer interrupts
Date: 14 Dec 2000 17:10:12 GMT
I have a quick question here about how linux (for the i386) handles timer
interrupts and how processes are rescheduled. I have noticed that timer
interrupts (10 ms granularity type) cause the counter associated with the current
process to be decremented, and if that counter reaches 0, a need_reschedule bit
it set. However, I am wondering when the schedule() function is called to
schedule a new process?? I have noticed some places it is called like:
return from system call, exit, block (on io or wait_queue)
However, I assume it has to be called somewhere else, like from the timer_bh
handler, because if not, a user space process which has something like the
while(1);
would never give up control of the cpu.. so, does anyone know where the call
to schedule() is made???
thanks,
Matthew Impett
University Of MD
------------------------------
From: "family.luff" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: PCMCIA card installation
Date: Thu, 14 Dec 2000 08:24:08 -0000
Jerome Corre <[EMAIL PROTECTED]> wrote in message
news:908kdc$dra$[EMAIL PROTECTED]...
> when card services is instaled properly the command
> cardctl eject <socket nb>
> will unload the driver for the card in the socket you've specified so
> that you can eject it.
Modern versions of the card manager cardmgr (which should be started
automatically - if not, there's probably something in /etc/rc.d/init.d/ to
do it. failing that, just run the binary ;-) will support hot-swapping and
automatically unload the correct modules on ejection (and, likewise, load
them on insertion). That said, I'm only *sure* about my chipset, but I
should imagine any proper PCMCIA support would include hot-swap
capabilities.
Check /etc/pcmcia/config
Meredydd
--
Just go with the flow control, ride the crunches, and when you get a prompt,
TYPE LIKE HELL!
------------------------------
Crossposted-To: comp.lang.c++,gnu.misc.discuss
From: [EMAIL PROTECTED] (Mike Stump)
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Thu, 14 Dec 2000 17:54:50 GMT
In article <[EMAIL PROTECTED]>,
Pete Becker <[EMAIL PROTECTED]> wrote:
>If you get into court, your "informed opinions on a newsgroup" are
>worthless.
And that is our point. If one heeds the informed opinions on a
newsgroup, one greatly reduces the risk of getting hauled into court.
It may, or may not help _in_ court once your there, but one excellent
way of not loosing in court, is to not be there in the first place.
An ounce of prevention is worth a pound of cure.
I think a good balance for me between heeding advice on a newsgroup
and the sound legal advice is about 10 to 1. What balance do others
feel is best?
------------------------------
Crossposted-To: comp.lang.c++,gnu.misc.discuss
From: [EMAIL PROTECTED] (Mike Stump)
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Thu, 14 Dec 2000 17:46:56 GMT
In article <[EMAIL PROTECTED]>, jbs <[EMAIL PROTECTED]> wrote:
>Austin Ziegler wrote:
>That's probably not the biggest difference. The biggest difference
>is that open source licenses are enforced largely by community
>consensus and peer pressure.
I agree. And in fact, I like a world where people can operate this
way, and don't need to go to court to work together. Some companies
might not mind loosing a $10,000 judgement in a copyright case, but
might not like a $100,000 loss in good will that not conforming to
peer pressure and working with the community might bring. Then again,
I may be an eternal optimist.
Apple lost good will with the FSF and look where it got them.
:-)
------------------------------
From: jbs <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Thu, 14 Dec 2000 10:15:01 -0800
Mike Stump wrote:
> Apple lost good will with the FSF and look where it got them.
> :-)
It probably got them knocked down harder than you might think. I
believe that the cold shoulder Apple has gotten from the free software
community with their Darwin project is partially due to remnants bad
will from the days of the FSF boycott, along with the defects in their
license which the FSF and free software community has identified.
Play nice and you get cooperation. Step out of line and you get
ostracized.
------------------------------
From: Pete Becker <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c++,gnu.misc.discuss
Subject: Re: Compiling C++ programs with GCC --> no GPL license implications
Date: Thu, 14 Dec 2000 13:28:44 -0500
Mike Stump wrote:
>
> I think a good balance for me between heeding advice on a newsgroup
> and the sound legal advice is about 10 to 1. What balance do others
> feel is best?
14.7. Just as meaningless.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.os.linux.mandrake,alt.os.linux.slackware,alt.uu.comp.os.linux.questions
Subject: Re: Does kernel 2.2.18 need to be patched for raid???
Date: Thu, 14 Dec 2000 18:32:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Does mingo's raid patch raid-2.2.18-A2 get applied to kernel 2.2.18?
no, it's for a 2.2.17 kernel.
but i have nfi whether 2.2.18 needs a patch to be current with the state
of a properly patched 2.2.17 kernel.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Joseph Virzi <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: linux.redhat.development
Subject: Re: Linux GUI programming
Date: Thu, 14 Dec 2000 10:57:35 -0800
I use computers to control thousands of lines of telephones, with the aid of
custom hardware. A more antiquated me was happier with a 32-bit extended DOS
than I was with Windows, at least for hardware development and driver
debugging.
As I needed to add network capabilities and GUI control interfaces, I switched
to NT/95, where I found a difficult time characterizing my operating
environment ( interrupt response times, timer granularities, and so forth )
The GUI was good, however.
Under Linux, I can characterize the operating environment, and equally
important, I can expect Linux to work the same way time after time. Microsoft
products rarely behave the same way twice.
Yes, I have performed the segmentation faults and kernel-cides in Linux. I
expect to as I am debugging a driver. I've even killed a few hard disks, and
have had to reinstall Linux, but it was because Linux did what I told it to do
( which is not what I exactly intended )
Lastly, the time between development cycles, including
recompilation/installation/removal of dynamically installed drivers, can be as
short as 5 seconds. Gotta love that.
-Joe
Joshua Schaeffer wrote:
> > I would like to write a GUI based application, just like I can with
> > Windows. As an application and device driver writer, I have been forced
> > to use Windows because of the GUI. In all other respects, Linux is
> > superior.
>
> As an honest question and not flamebait, why do you feel Linux is superior
> to Windows as far as architecture is concerned?
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: timer interrupts
Reply-To: [EMAIL PROTECTED]
Date: Thu, 14 Dec 2000 18:52:00 GMT
On 14 Dec 2000 17:10:12 GMT, Matthew Impett <[EMAIL PROTECTED]> wrote:
>I have a quick question here about how linux (for the i386) handles timer
>interrupts and how processes are rescheduled. I have noticed that timer
>interrupts (10 ms granularity type) cause the counter associated with the current
>process to be decremented, and if that counter reaches 0, a need_reschedule bit
>it set. However, I am wondering when the schedule() function is called to
>schedule a new process??
It is called when returning from a system call or interrupt. The two are done
by the same code because a system call is a software interrupt.
>I have noticed some places it is called like:
>return from system call, exit, block (on io or wait_queue)
>However, I assume it has to be called somewhere else, like from the timer_bh
>handler, because if not, a user space process which has something like the
>while(1);
>would never give up control of the cpu..
Sure it would. The timer interrupt you just mentioned would do the trick.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.os.linux.mandrake,alt.os.linux.slackware,alt.uu.comp.os.linux.questions,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.hardware,comp.os.linux.setup,linux.dev.kernel
Subject: Re: Kernel won't mount raid0
Date: Thu, 14 Dec 2000 19:05:21 GMT
Reply-To: [EMAIL PROTECTED]
I boot Software Raid1 (mirroring) and it works well.
Support for this included setting the partition types as fd (Raid
Autodetect) with fdisk, Compiling ALL raid support in the kernel,
including boot support, and Following the instructions here:
http://www.linuxdoc.org/HOWTO/Boot+Root+Raid+LILO.html
It took me over 72 hours to figure stuff out, but I am comfortable
with it now. I will be going into production with bootable Raid 1.
It wasn't the setup that was difficult, it was recovering from
simulated failures that was time consuming.
I am still looking into ide, vm and raid patches as I am not sure
which is the most reliable kernel/patch configuration, but I know that
I haven't had any problems with 2.2.17-21.
I have found the simplest and quickest way to react to a single drive
failure in bootable Raid 1 is to do the following:
SWITCHING FROM RAID 1 TO NON-RAID
--Note, this procedure includes a dos-bootdisk with loadlin.exe and a
functional kernel that works with your hardware. It also assumes that
you are familiar with partitioning, and have knowledge of the linux
boot process. It also assumes use of the ext2 filesystem.
1) convert raid partitions to 83 with fdisk
2) remove /etc/raidtab
3) modify /etc/fstab to mount non-raid partitions
4) modify /etc/lilo.conf to non-raid bootable configuration and
execute lilo
5) reboot
If you cannot access your filesystems since your bootable raid device
is busy, or you are in maintenance mode and the filesystem is read
only, you can use the rescue option of the distro cd, or a
root-bootdisk to mount the filesystems. I do not recommend the use of
Tom's root-bootdisk to do any of this with because of the older
libraries and filesystem versions.
I realize that linux raid has hot add and hot remove features, but I
do not have hot swap hardware and I also have not been able to
overcome the issue of /dev/md0 being busy when trying to do a raidstop
or a partition table modification, so inevitably, a reboot is
necessary, IMO, with bootable raid 1.
My current configuration is Mandrake-7.2 with the Mandrake kernel
2.2.17-21.
Tyan Tiger 133 VIA Chipset
Dual PII-400 in SMP mode
640MB PC-133
(2) 3Com905c 10/100's
(1) Dec21040 Tulip
(2) Western Digial 20GB hard disks (ATA-33) Raid 1
(1) Adaptec 2940U
(2) Seagate Baracuda 4GB hard disks Raid 1 (Boot)
Nvidia TNT2 AGP v.95 driver
Voodoo II PCI
Sound Blaster 32 ISA w/IDE
48x Cd-Rom
Zip drive
My best suggestion is if you are going to play with Software Raid on
Linux, then backup all of your directories to a separate drive that
you can restore from. Ideally, be doing this with a test box and not a
production machine.
Best regards and many thanks to Michael Robinton for a well written
HOWTO.
Charles Wilkins MCNE MCP A+
On Mon, 4 Dec 2000 09:33:06 +0100, "Peter T. Breuer"
<[EMAIL PROTECTED]> wrote:
>In comp.os.linux.misc Stephan A Suerken <[EMAIL PROTECTED]> wrote:
>> "Peter T. Breuer" <[EMAIL PROTECTED]> writes:
>>> In comp.os.linux.misc Stephan A Suerken <[EMAIL PROTECTED]> wrote:
>>> > /dev/md0 raid0,16k,0,802eab69 /dev/hda3 /dev/hdc2
>>> > oo Kernel 2.2.18pre23 and Kernel 2.2.17pre6 (both tried), with the
>>> > necessary RAID options (raid0, boot) enabled. Not as modules of course.
>>> > image = /vmlinuz
>>> > label = Orlok_Kernel
>>> > root = /dev/md0
>>> > read-only
>>> > vga=4
>>> > append="md=0,0,16,0,/dev/hda3,/dev/hdc2"
>>>
>>> waaaaaaaaaaah. Raid mirror root. Bad bad bad. Can you really do this?
>
>> No! Good (tm) idea! ;) However, I never talked of mirror mode.
>
>Oh, raid0 isn't mirror? What is it then? Oh, I see, raid1 is simple
>mirroring and raid0 is striping. Sorry, I really only use linear mode
>in earnest, so I forgot.
>
>> There is support to boot linear and striped (raid0) arrays since
>> 2.2.x. I can really do this. Or, that is, I should really ought to be
>> able to be doing this ;).
>
>Yes, I know. However, very few people are doing so, and I doubt if
>anyone is doing so on a pre-release kernel. Go back and try it on some
>other kernels.
>
>>> > ---
>>> > EXT2-fs error (device md(9,0)): ext2_check_descriptors: Block bitmap for group
>64 not
>>> > in group (block 3670038)!
>
>That block is very far upstream for a root device! Your root is at
>least 60MB in size. Well, I suppose that's OK.
>
>>> > EXT2-fs: group descriptors corrupted!
>>> > ---
>>>
>>> Yes, well, not surprised. Go find a kernel that is guaranteed to do
>>> raid mirror root,
>
>> As said above. All kernels >=2.2.0. There is only the uncertainty of
>> me being able to read or not.
>
>And whether or not it's been messed up in the pre-release you are
>looking at.
>
>>> CONFIG_BLK_DEV_MD=y
>>> CONFIG_MD_MIRRORING=y
>>> CONFIG_MD_BOOT=y
>
>> I don't need MD_MIRRORING (raid0 only), although I actually have it in
>> the kernel. As for the rest, I have it all of course.
>
>> Imho, there must be some slight difference in creating the /dev/md0
>> device between doing it from userspace via raidtools, or directly in
>
>Well, did you say you chunked at 16? 1KB chunks would be normal if the
>device file system has 1KB blocksize.
>
>> the kernel via boot options. The second imho most likely thing is that
>> I give the wrong chunk size factor. Kernel's md.txt isn't really clear
>> about that.
>
>It shouldn't matter, provided your whole device size is a multiple, of
>course.
>
>Why are you striping root? I can't think of an advantage. Root is
>essentially only read once for daemons and libs and stays in memory
>thereafter, so you don't get a speed up. There would be an advantage
>(robustness) in having a mirrored root.
>
>Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: changing BASH's path searching
Date: Thu, 14 Dec 2000 17:35:49 +0100
Josef Moellers <[EMAIL PROTECTED]> wrote:
> "Peter T. Breuer" wrote:
>>
>> OK, I'll bite ...
>>
>> Josef Moellers <[EMAIL PROTECTED]> wrote:
>> > There's more to rpm and friends than just injecting files here and there
>> > into a directory tree, checking dependencies for one and the most
>> > important thing: documenting what's installed.
>>
>> I dump a list of the tar file into /var/log/packages.
> Hmm, exactly which version/patchlevel of that binary did you install?
The one I said I did, both in the name of the file holding the list and
inside the list, under the heading VERSION:
>> updatedb takes less than 2 mins on my P450.
> You haven't seen what I've seen ... I'm not talking tens of gigabytes
> ...
I'm talking 5GB.
> Well, my job involves helping customers, i just KNOW they don't read
> READMEs!
Your customers pay you to read for them? Good. Poor power to your
elbow. I'm not that dumb.
> And there is more than just dynamically linked libraries that some
> programs need. There is other packages with executables that may be
> needed.
In that case they'd better document it, or the author of the software
will get an earful from me.
>> I move the list into /var/log/removed_packages. Removing the installed
>> files is of course a matetr of xargs rm -f < /var/log/packages/foo.
> No it's not. It's also reversing all modifications made to some
> configuration files of other packages. Example: Installing a networked
I would never do such a thing.
> server might modify /etc/inetd.conf. Neither is this entry made by "tar
It WOULDN'T. That's MY business. A package has no right to add ANY
line to MY system without MY say-so. And when I do it, I'll reverse it,
if I feel like, thank you.
> xvzf foo.tgz" nor is this entry removed by "xargs rm -f <
> /var/log/packages/foo". Also, removing a package might break
> dependencies (suddenly a binary needed by package bar is missing).
I don't remove packages that are needed my other packages :),
and if ever I accidently do, I put it back again sharpish (tcl/tk for
versions back to 4.0 is an example of stuff I've several times given up
on and removed, only to have to go and put back as I discover some
other misbegotten scribble that relies on 4.0).
>> No, it's not. They are doing one thing very wrong: keeping the info in
>> an unreadable format that nobody else can read or manage. At least rpm
>> does that. Dpkg (and installpkg) does not. Their databases are ascii.
> That is a point I can agree with. I just _hate_ binary files if the
> information can be stored in ASCII. If only they had used some other
> format, e.g. a db file so one could examine it with Perl or the like.
Peter
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Subject: Re: Problems of DHCP setting
Date: Thu, 14 Dec 2000 19:58:07 -0000
In article <91ab2h$[EMAIL PROTECTED]>,
Michael <[EMAIL PROTECTED]> wrote:
>No subnet declaration for the eth0 (my ip address here)
>Please write a subnet declaration for the network segment to which interface
>eth0 is attached.
>exiting.
The easiest way to deal with this is to add the option "-i eth1" to
the dhcpd invocation line. This will tell the daemon to "listen" only
on that one interface, and to completely ignore the eth0 interface on
which you don't want to provide DHCP service.
>Another, when I run "ifconfig", I also found that on eth0 shown "Tx
>packets:3233 errors:3 dropped:0 overruns:0 carrier:3", is it normal in
>"errors:3"?
Not terribly unusual. You can see errors (e.g. no-carrier) as a
result of plugging or unplugging your Ethernet cable, power-cycling
the external cable-modem, collisions or noise on the net, sunspots, etc.
As long as you only see a handful of errors, I wouldn't worry about it.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
