Linux-Development-Sys Digest #923, Volume #7 Thu, 1 Jun 00 00:13:14 EDT
Contents:
Detecting whether another process has a file open (Nick Craig-Wood)
Re: Increase the priority of a thread... how? ("Norman Black")
Getting "real" memory address? (Joe Rouvier)
Re: viruses on Linux (Dima Maziuk)
Re: Winmodems )Re: Need ideas for university funded project for linux) (Victor
Wagner)
Re: Winmodems )Re: Need ideas for university funded project for linux) (Victor
Wagner)
Re: Winmodems )Re: Need ideas for university funded project for linux) (JEDIDIAH)
Re: 2 GB File size limit? (Christopher Browne)
GCC EGCS libc libg (John Gluck)
Re: coredump files (Peter Pointner)
CFV: comp.os.linux.embedded (Dave Cornejo)
Re: Detecting whether another process has a file open ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nick Craig-Wood)
Subject: Detecting whether another process has a file open
Date: Wed, 31 May 2000 20:15:56 GMT
What I need is a foolproof way of detecting whether another process
has a file open on the local machine. My program needs to process
files in a directory after they have been completely written from
another process (or possibly from a network file system).
fuser works quite well, but it has to do an awful lot of work to
decide whether a file is open (it looks through every directory in
/proc/[0-9]*/ and then looks at the links of the directories within
it. On my system that is over 1000 directory entries! It also
doesn't find all processes unless you are root (or you setuid fuser)
and it doesn't (always?) find kernel accesses either.
Given that I don't have any control over the process which is creating
the files (I can't make it use locking or any renaming scheme) what
can I do? It seems that the kernel knows the answer (when you unlink
an inode it doesn't disappear unless the number of links and the
number of processes with the inode open are both zero). I should be
able to ask it given a filing system and an inode is this in use. I
haven't found a way to do that though - I couldn't find any system
calls which take an inode number.
Any ideas?
TIA
--
Nick Craig-Wood
[EMAIL PROTECTED]
------------------------------
From: "Norman Black" <[EMAIL PROTECTED]>
Subject: Re: Increase the priority of a thread... how?
Date: Wed, 31 May 2000 14:33:42 -0700
Reply-To: "Norman Black" <[EMAIL PROTECTED]>
> I am porting a win32 app over to Linux.
I thought this might be the case.Once you get the app going and testing
shows you need a higher priority for the message handler then you can get
into the need to use real time scheduling on the message handler thread.
Yes, that requires you run as a super user, but then that is a feature of
the operating system.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
"Tom Thorne" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> >What problems are you seeing in your app to need a priority change.
>
> I am porting a win32 app over to linux. It has an ip message handler
> thread that runs (on win32) at a higher priority than other threads in
> the app.
>
> ...so I'll just try it as SCHED_OTHER and hope for the best.
>
> Thanks
>
>
> Tom Thorne <tomt at flyingpig dot com>
------------------------------
From: Joe Rouvier <[EMAIL PROTECTED]>
Subject: Getting "real" memory address?
Date: Wed, 31 May 2000 15:15:35 -0700
How do I translate the memory address returned by kmalloc() or
get_free_page into the "real" hardware memory address?
Also, how can I make sure that this memory doesn't get moved or swapped?
Thanks
------------------------------
From: Dima Maziuk <[EMAIL PROTECTED]>
Subject: Re: viruses on Linux
Date: Wed, 31 May 2000 17:14:19 -0500
Mario Klebsch wrote:
>
> [EMAIL PROTECTED] (Mike Dowling) writes:
>
> >I'm curious. Are there any mail user agents for Linux out there that
> >can automatically execute programs?
>
> It is not a user agent, but sendmail has already been (mis)used to execute
> program (with root permission) several times. :-(
>
Web browsers are not mail user agents, but they can execute Java/script
if you let them. Whatever security holes there may be in Java/JS
implementation, they should be limited by
> The Linux (and Unix) concept of users and file access permissions...
Dima
--
Mirrors and copulation are abominable
because thay multiply entities.
-- J. L. Borjes
=====================================
Sweetmorn, 5 Confusion 3166, 188:3:4 (1)
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: 31 May 2000 09:51:34 +0400
In comp.os.linux.misc [EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] (Victor Wagner) writes:
: [using internal power supply connectors to drive external devices]
:> But you have various connectors inside case - for hard disks and so on.
:> Have ever seen how indicators on front panel or 486's coolers are
:> connected to them? Solder a long cable to such a device (female and
:> male connectors connected with 5cm of cable) and you only need to find a
:> hole in case to lead this cable outside.
: In so doing, of course, you run the risk of introducing unpleasant
: interference from the external world. And you also drive the PS
: harder, which makes it heat up faster and last longer.
Of course, you've to do some calculations before doing so.
There are typically figures of allowed 5v and 12v output on the
case of power supply, and it is typically known how much power
particular device consumes.
But consider example of external zip-drive:
If you attach internal zip-drive to the main power supply,
it withstands it.
If you insert just another SCSI controller in the mother board, it
withhands it.
Now you get scsi controller and zip-drive wrapped into the plastic case
just outside your system block. Would you expect something wrong if you
power it from main power-supply?
Really, main reason was following:
Separate power supply units are just not designed for 24x7 operations.
Main power supplys of system blocks are.
I need some devices i.e. modem, operate 24x7 (be ready for call out or
call in).
These power units are not designed to just hang in the wall outlet,
when nothing connected to it. Main power supply too, but there is always
motherboard and hard disks. So if you power thing which you only seldom
use, such as scanner from internal power supply, you can just switch it
on and off using its own power switch, without searching for right
transwormer in long row of wall outlets.
: Maybe I'm a special case, but I already ruined a motherboard by
: driving it from an inadequate PS. And I burn through roughly one
: PS per year. Bear in mind that, with that one exception, all the PSes
: have been at or above the rated level. I don't want to think how fast
: I'd be flying through 'em if I started hooking in all the other crap
: I've got.
In Russian newsgroups, in such cases people usially refer to /dev/hands
or handsd(8). Of course, my solution is for people who at least pass the
university course of physics, and better have some engineering trainig,
so they can sum up numbers from documentation on devices, and compare it
with number on power supply. To be honest, I don't do soldering myself -
I ask my friend who is qualified radio amateur.
: --
: Eric P. McCoy ([EMAIL PROTECTED])
: non-combatant, n. A dead Quaker.
: - Ambrose Bierce, _The Devil's Dictionary_
--
The whole history of computers is rampant with cheerleading at best and
bigotry at worst.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: 31 May 2000 09:58:56 +0400
In comp.os.linux.misc JEDIDIAH <[EMAIL PROTECTED]> wrote:
: Nope. It's actually quite simple to manipulate the IRQ assignments
: in a modern BIOS. If your COM2 isn't already occupied by something
: else then there isn't going to be any "fiddling" at all actually.
: This is especially true for a modem that comes preset from the factory
: to use COM2.
: As far as "plugging in a connector" constituting 'installation', that's
: just assinine. If that sort of thing bothers you (plugging something
: into a socket) then you need to move to Lancaster county.
Sort of thing which bothers me is
1. Making sure that no long-running backgroung computation job is
running
2. Tell all my family members, that they cannot use their X terminals a
while
3. disconnecting all the cables from machine.
4. Lifting machine from behind my desk where it usially rests happily
5. Unscrewing the case
6. Now comes the thing which you only meant as installation of the card
7. Booting machine outside of its usial place to check if card installed
correctly
8. Shutting it down again and putting into the usial place.
9. Connecting all cables back again
10. Booting it and checking if it sees anything it should see, including
X terminals.
:>
:>External modems are ones whose installation doesn't interrupt system
:>operation. You bring in from shop, you connect it, you turn it on, and
:>other users of your machine do their work in the same time.
: As 'downtime maintenance' goes, plugging in an ISA modem is
: waaay down on the list in terms of turnaround time and end
: user deprivation. Nevermind the fact that not every random
: PC is going to be something 'mission critical' where HA is
: required.
X terminals is the key word. Typically I have to do such kind of
maintainance in deep night, to be sure than nobody of my household have
to finish some urgent work just now.
: Although, if your power grid is like your coms net, any talk
: about HA is really absurd anyways.
Power varies from 150 to 260V but there is nothing good UPS cannot cope
with.
Anyway, if there is a black out, X terminals would go down first,
becouse they aren't connected to UPS, and there would be no trouble
taking machine down too.
--
<Skyhook> Where is 'bavaria' proper? I thought it was austria.
-- Gesehen auf #Linux
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Winmodems )Re: Need ideas for university funded project for linux)
Date: Wed, 31 May 2000 23:34:02 GMT
On 31 May 2000 09:58:56 +0400, Victor Wagner <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.misc JEDIDIAH <[EMAIL PROTECTED]> wrote:
>
>: Nope. It's actually quite simple to manipulate the IRQ assignments
>: in a modern BIOS. If your COM2 isn't already occupied by something
>: else then there isn't going to be any "fiddling" at all actually.
>
>: This is especially true for a modem that comes preset from the factory
>: to use COM2.
>
>: As far as "plugging in a connector" constituting 'installation', that's
>: just assinine. If that sort of thing bothers you (plugging something
>: into a socket) then you need to move to Lancaster county.
>
>Sort of thing which bothers me is
>1. Making sure that no long-running backgroung computation job is
>running
If you find this difficult, you shouldn't be running a general
purpose operating system.
>2. Tell all my family members, that they cannot use their X terminals a
>while
As if "hey, mebbe I should just wait" is such a brain wracking
contemplation. REAL sysadmins have to be able to schedule downtime
occasionally, forget about individuals with big heads.
>
>3. disconnecting all the cables from machine.
Why? This is simply uncessary.
>4. Lifting machine from behind my desk where it usially rests happily
>5. Unscrewing the case
>6. Now comes the thing which you only meant as installation of the card
>7. Booting machine outside of its usial place to check if card installed
>correctly
>8. Shutting it down again and putting into the usial place.
>9. Connecting all cables back again
>10. Booting it and checking if it sees anything it should see, including
> X terminals.
You simply have a poorly maintainable 'server configuration'.
[deletia]
You aren't exactly running the Unisys corporate backup library here.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.hardware
Subject: Re: 2 GB File size limit?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 00:35:05 GMT
Centuries ago, Nostradamus foresaw a time when Grant Gray would say:
>[EMAIL PROTECTED] wrote:
>> is there a 2 GB file size limit on Linux? A friend of mine is doing some
>> Video editing on Windows and I was just curious whether he would be having
>> the same problem under Linux.
>>
>ext2 is 32bit and does have the 2gb limitation (i think there are workarounds
>for it), ReiserFS is 64bit and therefore has no appreciable (at least not for
>the next few years) file size limit.
All rubbish.
ext2 permits (and has, for a couple years now) file sizes up to 2TB,
but is throttled, on 32 bit platforms, to 2GB, because the file
descriptor format used, by default, in virtually all applications, is
limited to 32 bits on 32 bit platforms.
ReiserFS does _absolutely nothing_ to contribute to improvement with
regards to this limitation.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/linuxkernel.html>
Warning: Dates in calendar are closer than they appear.
------------------------------
From: John Gluck <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.gcc,linux.dev,comp.os.linux.questions,linux.dev.kernel
Subject: GCC EGCS libc libg
Date: Thu, 01 Jun 2000 01:27:59 GMT
Hi
I am trying to figure out some compiler/lib choices. Being a bit new at
this I have a few questions I can't seem to find a satisfactory answer
for.
1- There is a Pentium optimised compiler that appears to be based on
gcc. Is it safe for compiling kernels and libs as well as other apps for
linux???
2- Egcs seems to be the new order for gcc. I can't seem to find any egcs
source tar files. All I find is gcc. Which are egcs files???
3- What is the difference between libc5 libc6 and libg (or is it
glibc)???
I am running linux (originally SUSE 6.3) with the 2.4-test1 kernel
compiled.
I don't mind being on the bleeding edge (I do this for fun). But I do
want to know what works and what's broke.
I do software design for a living. Currently I do RTOS design at Nortel.
One of my own systems is a Dual Pentium III, 256Meg RAM, SCSI and IDE
drives, a 10baseT port and a 10/100baseT port, an SB Live, Matrox G400
32Meg Dual Head, USB ports and the usual Serial and parallel ports. I
have an ADSL modem as well as a regular 33.6K dialup modem. The other 2
systems are a Celeron and an old Pentium (1st incarnation)
I need PPOE for the ADSL which I haven't quite gotten working yet. But
then I haven't really put any effort into it yet.
Anyway, I would very much like to get involved in some
testing/debugging/testing of linux. Very much preferably the bleeding
edge stuff..
Note: This is for my own amusement and has nothing to do with my
employer.
I would appreciate if anyone who replies e-mail me as well as post to
the NG
TIA
John Gluck
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: coredump files
Date: 1 Jun 2000 04:38:03 +0200
David E. Fox <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, John Gluck
> <[EMAIL PROTECTED]> wrote:
>>
>> I have never really looked at the mechanism for producing coredumps. I
>> think it's in the kernel somewhere. I suppose it would be possible to
>> change it so that it does something like append the date and time to the
> Sure it's in the kernel (somewhere) :).
> ISTR that early versions of Linux added the process name to the
> core - like 'core.ls' for instance. However, that functionality was
> removed fairly quickly.
It is easy to reenable that functionality.
The following is from /usr/src/linux/fs/binfmt_elf.c, kernel 2.2.13:
memcpy(corefile,"core.",5);
#if 0
memcpy(corefile+5,current->comm,sizeof(current->comm));
#else
corefile[4] = '\0';
#endif
file = filp_open(corefile, O_CREAT | 2 | O_TRUNC | O_NOFOLLOW, 0600);
Peter
------------------------------
From: Dave Cornejo <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
news.announce.newgroups,news.groups,comp.arch.embedded,comp.os.linux.portable,comp.os.linux.announce
Subject: CFV: comp.os.linux.embedded
Date: Thu, 01 Jun 2000 03:28:55 GMT
FIRST CALL FOR VOTES (of 2)
unmoderated group comp.os.linux.embedded
Newsgroups line:
comp.os.linux.embedded Linux operating system on embedded hardware.
Votes must be received by 23:59:59 UTC, 22 Jun 2000.
This vote is being conducted by a neutral third party. Questions
about the proposed group should be directed to the proponent.
Proponent: John Peterson <[EMAIL PROTECTED]>
Mentor: Jonathan Grobe <[EMAIL PROTECTED]>
Votetaker: Dave Cornejo <[EMAIL PROTECTED]>
RATIONALE: comp.os.linux.embedded
It is becoming apparent that the Linux operating system has a
very bright future in the area of embedded applications; internet
appliances, wireless internet access, personal digital assistants,
television set top boxes, medical instruments, dedicated control
systems, etc. The potential for the growth of Linux in this area is
highlighted by the fact that roughly 95% of all newly manufactured
microcomputer chips are used for embedded applications.
Industry has already embraced Linux for use in embedded applications
for several reasons. The cost of licensing a commercial operating
system and the power of the open source development model are some
of the more prominent ones. The TiVo personal video recorder,
and the Empeg MP3 car player are two examples of consumer products
that utilize embedded Linux. Samsung has recently announced plans to
market the world's first Linux based PDA, named Yopy. Sony already
uses Linux based systems for developing applications for it's
Playstation2 game machine. The industry has further demonstrated
it's commitment to Linux by the recent announcement of the formation
of the Embedded Linux Consortium (ELC). It will consist of roughly
50 member companies including IBM, Lineo, Motorola and Red Hat.
Linux development has historically been oriented toward desktop
and server applications and the current comp.os.linux.* hierarchy
largely reflects this heritage. The unique nature of the technical
issues of using Linux for embedded applications, and the potential
for enormous growth are the two main reasons for the proposal of
this new Usenet newsgroup.
There will be some overlap of the charter of the proposed group
with that of the existing comp.os.linux.portable newsgroup (using
the Linux OS on portable computers). This is unavoidable since
some embedded devices are designed with the intent to provide
portable computing resources of a rather general nature (PDAs for
example). However, the universe of embedded devices that would not
be classified as a portable computer is very large (e.g. TV set top
boxes, medical instruments). It is the contention of the proponent
that the proposed group is sufficiently disjoint from the existing
comp.os.linux.portable newsgroup that the efficiency and viability
of both groups would not be negatively impacted.
Topics related to the use of Linux on embedded processors are
already frequently discussed in several existing Usenet newsgroups
and mailing lists. Statistics for such postings during the period
from Jan 1, 2000 to Jan 31, 2000 are shown in the table below. The
Usenet statistics were gathered using "Power" keyword searches
from the Deja search engine at http://www.deja.com/home_ps.shtml
Newsgroup / Mailing List Posts Search Keyword
======================== ===== ====== =======
comp.arch.embedded 151 "Linux"
comp.dsp 41 "Linux"
comp.realtime 24 "Linux"
comp.os.linux.development.system 17 "embedded"
comp.os.linux.hardware 8 "embedded"
linuxppc-embedded mailing list 266 N.A.
linux-embedded mailing list 48 N.A.
linuxce mailing list 180 N.A.
uclinux mailing list 135 N.A.
---
Total Postings 870
Average Postings / Day 28 (870/31)
CHARTER: comp.os.linux.embedded
This newsgroup is intended to be a public forum for the discussion
of the development and use of the Linux operating system on embedded
hardware platforms. Topics considered appropriate for posting to the
group might include (but are not limited to);
o Software Related Topics
+ Embedded Linux distributions (e.g. Lineo Embedix, Mobile Linux)
+ Software APIs for embedded Linux development (e.g. Cygnus EL/IX)
+ Development of user applications for embedded Linux
+ Integrated Development Environments for embedded Linux
o Hardware Related Topics
+ Linux based emulators and debuggers for embedded hardware
+ Existing Linux support for specific hardware
+ Development of device drivers for embedded Linux
Topics that might appear welcome on the surface, but in fact are not
include; general questions about embedded hardware with no reference
to Linux, questions about embedded or real time programming that
are not specific to Linux, such as "What is multithreading?", or
"What is a deadlock?", etc.
One time postings of commercial product announcements or postings of
a commercial nature that are replies to another posted inquiry will
be considered appropriate. However, as in most other Usenet groups,
repeated or indiscriminant posting of commercial advertisements will
be prohibited. Postings using MIME, HTML formats are discouraged
since many Usenet readers do not use web browsers. The posting of
source code and binaries for the purpose of distribution shall be
prohibited. However, a small snippet of source code or a small patch
would be considered acceptable.
END CHARTER.
HOW TO VOTE:
Follow these instructions *exactly*! Votes are counted by computer.
You should send E-MAIL (posts to a newsgroup are invalid) to:
[EMAIL PROTECTED]
Please do not assume that just replying to this message will work.
Check the address before you mail your vote. Your mail message
should contain one and only one of the following vote statements:
I vote YES on comp.os.linux.embedded
I vote NO on comp.os.linux.embedded
Voter name:
If your mail software does not indicate your real name (for example,
AOL does not), include _exactly_ the statement above on a _separate_
line and add your name after the colon. Having your name in your
signature line is NOT enough! Do NOT join the lines together or
remove the words "Voter name"!
You may also vote ABSTAIN (which records an empty vote) or CANCEL
(which removes any earlier votes). ABSTAIN does not affect the final
vote count in any way but is listed, whereas CANCEL is not.
IMPORTANT VOTING PROCEDURE NOTES:
Standard Guidelines for voting apply. One vote per person, one
account per voter. Votes must be mailed directly from the voter to
the votetaker. Anonymous, forwarded or proxy votes are not valid.
Votes mailed by WWW/HTML/CGI forms are considered to be anonymous
votes. Votes from non-existent email addresses are not valid.
Vote counting is automated. Failure to follow these directions may
mean that your vote does not get counted. If you do not receive an
acknowledgment of your vote within three days contact the votetaker
about the problem. It's your responsibility to make sure your vote is
registered correctly. Duplicate votes are resolved in favor of the
most recent valid vote. Addresses, names and votes of all voters will
be published in the final voting results post.
The purpose of a Usenet vote is to determine the genuine interest of
persons who would read a proposed newsgroup. Soliciting votes from
disinterested parties defeats this purpose. Please do not distribute
this CFV. If you must, direct people to the official CFV as posted to
news.announce.newgroups. Distributing pre-marked or otherwise edited
copies of this CFV is generally considered to be vote fraud. When in
doubt, ask the votetaker.
DISTRIBUTION:
Pointers directing readers to this CFV will be posted in these groups:
alt.os.linux
comp.dsp
comp.os.linux.hardware
comp.os.linux.powerpc
linux.dev.laptop
linux.redhat.misc
Pointers directing readers to this CFV will be posted in these lists:
linuxppc-embedded mailing list
uclinux mailing list
linuxCE mailing list
linux-embedded mailing list
Real Time Linux mailing list
SA-1100' Linux mailing list
Yopy mailing list
A pointer directing readers to this CFV will be posted on this web site:
www.linuxdevices.com
--
Voting question & problems: Dave Cornejo <[EMAIL PROTECTED]>
Voting address: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Detecting whether another process has a file open
Date: 31 May 2000 20:13:50 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
may be you can look at 'lsof'
LSOF(8) LSOF(8)
NAME
lsof - list open files
Lsof revision 4.46 lists information about files opened by
processes for the following UNIX dialects:
..
Nasser
------------------------------
** 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
******************************
