Linux-Development-Sys Digest #649, Volume #7 Fri, 3 Mar 00 12:13:20 EST
Contents:
Re: glibc building problem (Jean-Christophe Praud)
Re: unmmaped area? ("KimJinKwon")
[Fwd: Problem with portmap on Redhat 5.2] (Wallace Barnes III)
Re: Absolute failure of Linux dead ahead? (David T. Blake)
Re: Absolute failure of Linux dead ahead? (Wolfgang Weisselberg)
Re: Absolute failure of Linux dead ahead? (Wolfgang Weisselberg)
Re: clone() and shared library heap allocations (Kaz Kylheku)
Re: mapping between VFS system calls and C library APIs (Kaz Kylheku)
Re: Moving our product line to Linux (Mario Klebsch)
Re: clone() and shared library heap allocations (Ulrich Weigand)
Re: Struct size and allocate problem! need help. ("P.G.Hamer")
Fieldbuses (Anders Larsen)
Re: clone() and shared library heap allocations ("Frank V. Castellucci")
Re: unmmaped area? ("Frank V. Castellucci")
Re: Documentation for developing usb device drivers (Georg Acher)
Re: Fieldbuses (Wolfgang's Kiste)
Re: unmmaped area? (Mathias Waack)
compiling with libc5 under a glibc2 system (Wolfgang's Kiste)
Re: Fieldbuses (Jeff McWilliams)
Re: Linux semaphore set ("Frank V. Castellucci")
Re: Documentation for developing usb device drivers (Toby Haynes)
Nonblocking connect() delays before returning (David)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jean-Christophe Praud)
Subject: Re: glibc building problem
Date: Fri, 03 Mar 2000 15:31:10 GMT
In article <[EMAIL PROTECTED]>,
Krik Lee <[EMAIL PROTECTED]> writes:
> Dear All:
>
> I want to build a glibc for arm processor.
> So, I got glibc2.1.2, gcc-2.95.2, binutils-2.9.5.0.27 and linux kernel
> 2.2.14
> to build a cross-platform version of them.
>
> After I successfully built binutils, gcc, and linux kernel, however, I
> encountered
> " ../elf/ld-linux.so.2: undefined reference to `__libc_global_ctors' "
> error messgae when I am building glibc!!
>
> Could anyone tell me how to solve this problem??
>
> Thanks !!
>
> kirk
>
I've got the same pb on i686. It vanished after I re-installed cross
binutils and gcc from scratch, and installed gnu make 3.77 and gettext-0.10.35.
For now, I succeded at building a libc, but the 'make check' fails...
I installed the libc and compiled a cross gcc, but executables compiled
with this setup don't work :
/usr/local/cross/i686-pc-linux-gnu/lib/libc.so.6 :
undefined symbol: _dl_initial_searchlist
still trying...
--
Jean-Christophe Praud - InfoBorn / Quiksilver Europe
Ph'nglui mglw'nafh Cthulhu n'gah Bill R'lyeh Wgah'nagl fhtagn.
------------------------------
From: "KimJinKwon" <[EMAIL PROTECTED]>
Subject: Re: unmmaped area?
Date: Sat, 4 Mar 2000 00:35:21 +0900
You can get unmapped area by telling the kernel not to use some memory area.
If you add like,
append="mem=60M"
to /etc/lilo.conf where you have more than 60MB of RAM, then you can have
total control of the physical ram starting from 60MB to
(whatever_you_have_more_than_60)MB.
You can get as much memory as you want by this trick. The linux kernel may
happily work with 4MB of RAM.
Hope it will help you.
"Weiguang Shi" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi, there:
> I am wondering if there are parts of the physical memory under Linux
> which are not included in the paging system (i386). I mean if there is
> physical memory which is not used for paging but rather reserved for
> other use in Linux.
> Can you give some clue or could you please give a pointer to further
> information?
>
> Thanks.
>
> Weiguang
>
> Weiguang Shi | E-mail: [EMAIL PROTECTED]
> Department of Computing Science |
http://www.cs.ualberta.ca/~wgshi
> University of Alberta | Office: CAB 481
> Edmonton, AB, Canada, T6G 2H1 | (O) (780)492-3927
>
>
------------------------------
Date: Fri, 03 Mar 2000 10:39:14 -0500
From: Wallace Barnes III <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: [Fwd: Problem with portmap on Redhat 5.2]
This is a multi-part message in MIME format.
==============9A302E0296EEED39D38BE531
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
==============9A302E0296EEED39D38BE531
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Path: spool0.news.uu.net!reader1.news.uu.net!not-for-mail
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 02 Mar 2000 11:00:26 -0500
From: Wallace Barnes III <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Bloomberg LP
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
Newsgroups: comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.x
Subject: Problem with portmap on Redhat 5.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 199.172.169.19
X-Trace: reader1.news.uu.net 952012826 24817 199.172.169.19
Hello All,
I ran into a problem trying to run the portmap daemon that comes
with the RedHat 5.2 distribution. It seems that the child process that
is forked off aborts after sending the following message to syslog:
"portmap[3018]: run_svc returned unexpectedly"
I checked the code and svc_run is a C extern function which is supposed
to never return. Does anyone no how to fix this apparent bug ? Please
Email me with your response as well. Thanks in advance.
-Wally
==============9A302E0296EEED39D38BE531==
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 3 Mar 2000 14:46:40 GMT
Reply-To: [EMAIL PROTECTED]
Grant Edwards <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, David T.
> Blake wrote:
>
> >There is one and only one reason that x86 still exists.
> >Microsoft.
> >
> >If they were capable and willing to port Windows to another
> >platform,
>
> NT has been available on the Alpha for quite a while. AFAIK,
> it's a dismal failure. Everybody I've talked to with an Alpha
> runs Unix.
The port was practically done by Dec, and still, M$ would not
port their other apps, like Office to 64 bit. So Dec wrote the 32
bit emulator, which ran like crap. NT on alpha always ran like
crap. Heck, Dec for a while had more NT engineers working on
alpha than Microsoft !
Microsoft had NO motivation to make a decent port. They OWN the
entire market of PC operating systems for desktops.
64 bit systems will be quite nice for Unix users, but Windows
users will see rough waters ahead.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Wolfgang Weisselberg)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 3 Mar 2000 16:29:08 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 02 Mar 2000 20:41:25 GMT,
Jon <[EMAIL PROTECTED]> wrote:
> On 2 Mar 2000 19:53:00 GMT, [EMAIL PROTECTED]
> (Wolfgang Weisselberg) wrote:
> > On Thu, 02 Mar 2000 17:52:16 GMT,
> > Jon <[EMAIL PROTECTED]> wrote:
> > > On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
> > > wrote:
> > How many machines do *you* know that are in active use today
> > *and* were so 15,20,30 years ago?
> 2 that I've worked with personally.
So, does a single pentium outclass them yet or do you need a dual
PII for that? The computing power of 20 years ago is not much
today compared to entry-level PCs. Not to mention their economic
use of several kWatts + aircon power. Not to mention having to
look for manufacturers for your core memory (for old machines).
The only case *I* know of would be *taadaaa* the space shuttle,
which uses (or at least used at the time of the Challenger) core
memory. No RAM chips. But then the coding standards and the size
of the programs is somewhat different to what Corps use.
> There are thousands of
> others... witness the demand for Cobol programmers that occured
> in 1999.
Code != Hardware.
> This assumes the hardware will be replaced. This is not always
> true. Take XYZ Corp. who just invested $UmpteenMillion in their
> new WhizBang5000 Unix-based computer system. There's a *very*
> good chance that system will still be there in 2038, operating
> all of XYZ Corp.'s critical accounting and MRP functions.
Sure. We are talking about quite a couple of generations here.
Both in hardware and in software. While I personally would like
to see Unix still being there 30 years from now, we must realize
that Unix is the oldest 'still in use' OS --- and it's just 30
years old. How old's Windows?
> Why
> replace it? It cost a whole lotta cash and it still works just
> fine.
And the electricity bill for a year could buy a more powerful
replacement, too. Not to mention hardware maintenance and getting
old style, really slow HDs, when everyone uses hi-speed 10'th
generation holographic memories of a couple of 1000 Exabytes size
as today we have 5GB drives ... and Terrabytes of 'RAM' in desk
machines.
> Beside that, how would XYZ explain to their investors that
> they need to spend $UmpteenMillions times 2 to buy an all new
> system, just because their old multimillion dollar machine can't
> figure out what year it is?
Well, more likely because code and feature bloat will make the
processing ability and the RAM being far too small for daily use.
And as the value of computers go ... how much is a just 10 years
old 386-sx 20, 4MB DRAM Memory, 40 MB MFM drive 14" monitor worth
today? Computers devalue fast. So why not replacing the 'scrap
value' ex multimillion system with something just as fast from the
srcap value alone?
-Wolfgang
------------------------------
From: [EMAIL PROTECTED] (Wolfgang Weisselberg)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 3 Mar 2000 16:33:51 GMT
Reply-To: [EMAIL PROTECTED]
On 3 Mar 2000 02:10:20 GMT,
Michael Sawyer <[EMAIL PROTECTED]> wrote:
> Joe Programmer writes a program, and does the "Right Thing," using
> sizeof(time_t) anywhere he has to know the actual size of the type.
And then he does the wrong thing:
> The program he's writing needs to keep some data on disk, which is not
> at all an uncommon request. He's choosen to keep them in binary
> files, to save storage space. Thus, he's got some structure
> Now, time_t gets promoted to 64 bits, and he goes to read his data
> back from his disk file.
And he did another wrong thing: not using a magic numer and/or a
version in his data headers, not to mention noting down the
structure there.
Joe Programmer was stupid.
[snip rest of argument based on the idea that there are no version
numbers]
-Wolfgang
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: clone() and shared library heap allocations
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Mar 2000 16:32:55 GMT
On Fri, 03 Mar 2000 06:57:17 -0500, Frank V. Castellucci
[EMAIL PROTECTED]> wrote:
>Thanks, I know about using the pthread interface. I assume that if you
>continue to use clone() and semxxx() AND link with libpthread but don't
>use it for the external app you get the best of both at the cost of
>memory and overhead.
If you use clone(), link with libpthread, and from a cloned thread call any
function that enters into libpthread, your program will most likely crash.
The LinuxThreads library assigns an extra context structure to each thread that
is created with pthread_create(). The entry points into the library fetch a
pointer to the calling thread's context structure.
The context structure is required for participation in all synchronization
activities.
You should be able to use the System V semaphore interface (if that's what wyou
mean by semxxx()) from a cloned thread, however, as long as you avoid calling
sensitive libc functions from that thread. Note that most of the stdio stuff
has POSIX threading hooks in it; for example, something as innocuous as
putc(FILE *) actually performs a lock and unlock operation on the stream
object. There really is no way to be sure which functions are okay and which
are not.
I would say that it's a bad idea to mix clone() and pthread_create() in the
same program. Either use clone(), and use your own synchronization to ensure
that only one thread at a time calls the C library (and do *not* link in the
threading library), or use the threading library and avoid clone().
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: linux.dev.c-programming
Subject: Re: mapping between VFS system calls and C library APIs
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Mar 2000 16:47:14 GMT
On Fri, 03 Mar 2000 09:11:00 +0000, Mace Gaël <[EMAIL PROTECTED]> wrote:
>
>--------------DB914C4FEC695957AE2046DB
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
Don't do that! Post in ASCII.
>
>Hi,
>
>For my own understanding, does someone can explain me the mechanism /
>implementation of the mapping between the VFS system calls and the
>standard C library APIs (e.g. glibc) ?
>
>If I'm not wrong, in the linux architecture, the VFS module presents
>several APIs (in <fs.h> such as sys_open, sys_statfs, etc.) which are
>unified system calls independent of the physical file system. At a upper
>level, I can find in the implementation of the standard C library (such
>as glibc) some related APIs (in <fcntl.h> such as open, stat, etc.).
>
>However, by studying the source code of the glibc library, I fall in
>some dead ends and never find direct (or indirect) relation between VFS
>interface and standard interface.
At the library level, you will not see the internal names like sys_open,
sys_statfs and so on. These sys_* names are just symbols used within the kernel
source code.
>By example for the glibc 2.1 implementation, in the file
>"sysdeps/generic/open.c"
You are looking at the wrong thing. Sysdeps generic contains largely stubs;
it's sort of a catch all so that, in theory, you can build glibc on a system
that doesn't have the proper support for these functions.
Try looking in
sysdeps/unix/sysv/linux/*
You aren't going to find a straightforward function definition for the open
function there, however. Most of the system calls are generated by macros.
These macros are in turn generated by a script when you build the library.
This process is largely indecipherable to mere human beings.
>/* Open FILE with access OFLAG. If OFLAG includes O_CREAT,
> a third argument is the file protection. */
>int
>__open (file, oflag)
> const char *file;
> int oflag;
>{
> int mode;
>
> if (file == NULL)
> {
> __set_errno (EINVAL);
> return -1;
> }
>
> if (oflag & O_CREAT)
> {
> va_list arg;
> va_start(arg, oflag);
> mode = va_arg(arg, int);
> va_end(arg);
> }
>
> __set_errno (ENOSYS);
> return -1; <<== does this function return
>always -1 ????
This is just a stub which returns -1 and sets errno to ENOSYS.
ENOSYS means ``this system call is not available on this platform''.
Obviously, this is not the version of __open() that is compiled
into glibc on Linux systems!!!
>}
>stub_warning (open) <<=== What's that ?
That is intended to create a special linkage directive understood by the GNU
tools.
When someone creates a program which implicitly or explicitly uses open(), and
this version of open() was accidentally built into the library, a warning will
be emitted that open() is implemented as a stub, and hence the program will
probably not work!
>weak_alias (__open, open) <<=== what's that also ?
It's just what it says it is. It creates a weak alias called ``open''
for the strong symbol __open. In effect, it means that the two symbols
resolve to the same address. However, open can be overridde, whereas
__open cannot. This lets other libraries, or applications, provide
their own implementation of open().
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Moving our product line to Linux
Date: Fri, 3 Mar 2000 13:06:59 +0100
"Edward Balassanian" <[EMAIL PROTECTED]> writes:
>As I understand it, X provides a shared memory facility that is effectively
>like writing direct to the frame buffer. This would be ideal for us. What
>we don't want is a ton of layering between us and a device since we are
>focused on high-bandwidth multimedia rendering.
If you use these features, take care, that your system keeps working,
when it is not available or cannot work. X11 can be used over the
network, while shared memory cannot. Running X11 applications over the
network is not that uncommon.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Subject: Re: clone() and shared library heap allocations
Date: 3 Mar 2000 11:13:47 +0100
"Frank V. Castellucci" <[EMAIL PROTECTED]> writes:
>Ulrich,
>Don't later versions of rtl INCLUDE LinuxThreads and respective support?
Yes, it's included in the glibc distribution. It still resides in a
separate shared object (libpthread.so), and is only linked into an app
if you specify -lpthread.
What glibc does contain is *calls* to pthread synchronization procedures,
but those calls use the 'weak symbol' mechanism to check whether the app
is linked with libpthread in the first place. If it isn't, glibc doesn't
perform critical section synchronization, because if the app isn't multi-
threaded, there's no need for critical section protection ;-)
Furthermore, even if you *do* link with libpthread, you still can't just
call clone(), as this doesn't set up all the internal libpthread data
structures etc. You must use pthread_create() in that case ...
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
------------------------------
From: "P.G.Hamer" <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,comp.os.linux.development.apps,comp.unix.sco.misc,comp.unix.sco.programmer,comp.unix.unixware.misc,tw.bbs.comp.linux
Subject: Re: Struct size and allocate problem! need help.
Date: Fri, 03 Mar 2000 10:30:36 +0000
Charles Bryant wrote:
> There's no inconsistencey. All of char, short, and long can be 32
> bits, in which case sizeof(long)==sizeof(short)==sizeof(char)==1.
Can you elaborate on this.
My dated 2nd edition of K&R states that sizeof() gives the size in /bytes/.
It also states that sizeof(char)==1.
While I'm not certain that these two statements are necessarily mutually
consistent, it does suggest that sizeof(32bit-type) == 4.
Or are we into standard-speak where a byte means anything that you
want it to, and you have to say octet to mean 8-bits?
Peter
------------------------------
From: Anders Larsen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Fieldbuses
Date: Fri, 03 Mar 2000 12:29:46 +0100
Hello,
I'm looking for different fieldbus implementations for Linux in order
to evaluate the feasibility of using some form of embedded Linux in our
products.
We would be interested in PROFIBUS-xxx, Interbus-xxx, DeviceNet, CanBus, Industrial
Ethernet and the like.
The more I can find, the better my chances of pushing Linux in here.
If you know of some (commercial or free) implementation, please let me
know (per e-mail, please).
Thanks in advance,
--
Anders Larsen
------------------------------
Date: Fri, 03 Mar 2000 06:57:17 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: clone() and shared library heap allocations
Ulrich Weigand wrote:
>
> "Frank V. Castellucci" <[EMAIL PROTECTED]> writes:
>
> >Ulrich,
>
> >Don't later versions of rtl INCLUDE LinuxThreads and respective support?
>
> Yes, it's included in the glibc distribution. It still resides in a
> separate shared object (libpthread.so), and is only linked into an app
> if you specify -lpthread.
>
> What glibc does contain is *calls* to pthread synchronization procedures,
> but those calls use the 'weak symbol' mechanism to check whether the app
> is linked with libpthread in the first place. If it isn't, glibc doesn't
> perform critical section synchronization, because if the app isn't multi-
> threaded, there's no need for critical section protection ;-)
>
> Furthermore, even if you *do* link with libpthread, you still can't just
> call clone(), as this doesn't set up all the internal libpthread data
> structures etc. You must use pthread_create() in that case ...
>
> --
> Ulrich Weigand,
> IMMD 1, Universitaet Erlangen-Nuernberg,
> Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
Thanks, I know about using the pthread interface. I assume that if you
continue to use clone() and semxxx() AND link with libpthread but don't
use it for the external app you get the best of both at the cost of
memory and overhead.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
Date: Fri, 03 Mar 2000 06:59:53 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: unmmaped area?
Fabrice Peix wrote:
>
> Mathias Waack wrote:
> >
> > Weiguang Shi wrote:
> > > I am wondering if there are parts of the physical memory under Linux
> > > which are not included in the paging system (i386). I mean if there is
> > > physical memory which is not used for paging but rather reserved for
> > > other use in Linux.
> >
> > The memory used by the kernel itself is not used for paging. But I'm not
> > sure, if this was the answer for your question...
> >
> > Mathias
>
> I thing you are wrong , paging system is made bye processor and all the
> memory
> is manage by MMU and so paging...
I think he meant that some pages (kernel) are mark non-swap or locked.
If so, then yes on kernel and if so elected by device drivers and even
user apps, neh?
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: [EMAIL PROTECTED] (Georg Acher)
Subject: Re: Documentation for developing usb device drivers
Date: 3 Mar 2000 12:15:03 GMT
In article <89npfj$kd9$[EMAIL PROTECTED]>,
"Pang" <[EMAIL PROTECTED]> writes:
|> Hi,
|> Can anyone tell me where I can obtain documentations for developing usb
|> device drivers for linux? Thanks.
http://www.linux-usb.org/
--
Bye
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
------------------------------
From: Wolfgang's Kiste <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Fieldbuses
Date: Fri, 03 Mar 2000 13:44:44 +0100
Hi,
for CAN-Bus there is something:
http://www.llp.fu-berlin.de/pool/newproj/CAN/
Maybe it is interesting.
Regards
Wolfgang Guldner
Anders Larsen wrote:
>
> Hello,
>
> I'm looking for different fieldbus implementations for Linux in order
> to evaluate the feasibility of using some form of embedded Linux in our
> products.
>
> We would be interested in PROFIBUS-xxx, Interbus-xxx, DeviceNet, CanBus, Industrial
>Ethernet and the like.
>
> The more I can find, the better my chances of pushing Linux in here.
>
> If you know of some (commercial or free) implementation, please let me
> know (per e-mail, please).
>
> Thanks in advance,
>
> --
> Anders Larsen
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: unmmaped area?
Date: Fri, 03 Mar 2000 13:47:50 +0100
"Frank V. Castellucci" wrote:
> I think he meant that some pages (kernel) are mark non-swap or locked.
> If so, then yes on kernel and if so elected by device drivers and even
> user apps, neh?
Yes, I think that was the question. If not, the author should give
us more informations...
Mathias
--
Mathias Waack | [EMAIL PROTECTED]
Tel.: +49 621 181 2717 Fax.: +49 621 181 2713
------------------------------
From: Wolfgang's Kiste <[EMAIL PROTECTED]>
Subject: compiling with libc5 under a glibc2 system
Date: Fri, 03 Mar 2000 13:50:22 +0100
Hi,
I need programms to compile with libc5 on a glibc2 system (SuSe 6.3).
I looked already in the glib2-howto, but this covers only the case when
you update your system from libc5 to glibc2.
Any ideas how it could work?
Thanks
Wolfgang
------------------------------
From: [EMAIL PROTECTED] (Jeff McWilliams)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Fieldbuses
Date: Fri, 03 Mar 2000 13:10:12 GMT
While we're at it, how about support for Allen-Bradley DataHighway+ ?
I'd love to be able to talk to a PLC-5 from a Linux box.
Jeff
--
Jeff McWilliams - Advanced Development Engineer, ACE Technologies
[EMAIL PROTECTED]
------------------------------
Date: Fri, 03 Mar 2000 08:24:40 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: Linux semaphore set
"Frank V. Castellucci" wrote:
>
> In my desire to support monitors into class libraries I am faced with
> scalabilty and performance issues in the implementation. What the ideal
> solution would be is sparse semaphore sets (either kernel or user space
> implemented). This would be robust enough to scale with the number of
> concurrent active objects that require the synchronization without
> delving into the solution space.
>
> Before moving forward, have I missed a command or api where the number
> of semaphores in a Linux semaphore set can be changed (+/-)?
Does that mean no?
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: Documentation for developing usb device drivers
Date: 03 Mar 2000 10:01:18 -0500
!! "Pang" == Pang <[EMAIL PROTECTED]> writes:
Pang> Hi, Can anyone tell me where I can obtain documentations for
Pang> developing usb device drivers for linux? Thanks.
Try the main site
http://www.linux-usb.org/
Cheers,
Toby
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
From: [EMAIL PROTECTED] (David)
Subject: Nonblocking connect() delays before returning
Date: Fri, 03 Mar 2000 15:11:24 GMT
When I connect() to some hosts, occasionally it does not return
immediately even though I have my socket-fd set to non-blocking. I've
seen delays as long as 5 or even 20 seconds, then an EINPROGRESS.
Is there a bug in the linux kernel? I believe it should return
EINPROGRESS immediately. I am running version 2.2.14 of the kernel.
Any ideas as to what might be causing this? How to get around it?
Whether it's a bug in the kernel?
Thanks,
David
[EMAIL PROTECTED] (remove the NOSPAMs before
sending).
------------------------------
** 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
******************************
