Linux-Development-Sys Digest #371, Volume #8     Sat, 23 Dec 00 01:13:12 EST

Contents:
  Re: [OT]Re: Problems with Linux kernel? ("Arthur H. Gold")
  Libraries (Andrew Clark)
  Re: Libraries (Craig Kelley)
  Re: make[3]: *** [ip_masq.o] Error 1 ([EMAIL PROTECTED])
  Re: kernel questions (Richard Chase)
  Re: RPC: Connection Refused (Ulf-Rainer Tietz)
  Re: Intel Easy PC camera - cannot be supported in Linux! (jtnews)
  Re: Intel Easy PC camera - cannot be supported in Linux!
  Re: Howto access kernel memory from user application ? (Juha Laiho)
  Re: Problems with Linux kernel? (Juergen Heinzl)
  VFAT problems with Kernel 2.2.18 (Keith Hulse)
  Re: Intel Easy PC camera - cannot be supported in Linux! ([EMAIL PROTECTED])
  Re: libc vs glibc and posix ("D. Stimits")
  Re: front ending libraries (even libc) ([EMAIL PROTECTED])
  Re: Intel Easy PC camera - cannot be supported in Linux! (Tim Roberts)

----------------------------------------------------------------------------

Date: Fri, 22 Dec 2000 13:55:03 -0600
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: [OT]Re: Problems with Linux kernel?

Philip Armstrong wrote:
> 
> In article <[EMAIL PROTECTED]>, Arthur H. Gold <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] wrote:
> >> Joshua Schaeffer <[EMAIL PROTECTED]> wrote:
> >> > I want to hear peoples' voices and opinions about what programmers do and
> >> > don't like about the Linux kernel.  All feedback will be integrated into the
> >> > design of yet another Open Source operating system.
> >>
> >> > To avoid flooding this newsgroup with non-relevant postings, please send any
> >> > remarks to the following e-mail address:
> >> > [EMAIL PROTECTED]
> >>
> >> > Many thanks in advance for your responses!
> >>
> >> FWIW, I think a major shortcoming of the Linux kernel (at least the Redhat one)
> >> is that I find it very difficult to use it without running into that damn
> >> command prompt thing.  And it is broken for very many of the DOS commands that
> >> I am used to using.  Even with the new windowing modules, such as gnome, (
> >> which I think is an excellent kernel feature), you still need to use the
> >> command prompt to do just about anything.
> >>
> >> :)
> 
> >I think you misunderstand what's actually _in_ the kernel.
> >The kernel comprises the lowest level of software -- the
> >part that interacts directly with the underlying hardware,
> >and provides for system calls (with which one generally
> >interfaces using the system libraries). That's all.
> >Everything else you mention is merely user-space code (like
> >whatever shell you're using, the windowing system,
> >whatever). Unless you're programming _very_ low level code,
> >you never interact with the kernel directly.
> 
> And I think you've just been had, hook line and sinker :)
> 
> Note the smiley at the end of the post to which you replied...
> 
Damn. I just now saw it (in the original message it was off
my screen). EEEEK I'VE BEEN HAD!!! (...like it's the first
time? ;-P)

--ag
-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
A: Yes I would. But not enough to put it out.

------------------------------

From: Andrew Clark <[EMAIL PROTECTED]>
Subject: Libraries
Date: Fri, 22 Dec 2000 20:46:15 +0000

Hi, could someone please tell me how to create libraries in Linux. In
Windows there's DLL's and am needing to do something similar for Linux.

If there is any sort of way to create libraries/modules could someone
please tell me, and also how to do runtime linking as like DLL's.

Thanks

Andrew

------------------------------

From: Craig Kelley <[EMAIL PROTECTED]>
Subject: Re: Libraries
Date: 22 Dec 2000 14:04:24 -0700

Andrew Clark <[EMAIL PROTECTED]> writes:

> Hi, could someone please tell me how to create libraries in Linux. In
> Windows there's DLL's and am needing to do something similar for Linux.
> 
> If there is any sort of way to create libraries/modules could someone
> please tell me, and also how to do runtime linking as like DLL's.

1) Look at the -shared command line for gcc's linking

2) man dlopen (on most Linux systems)

-- 
The wheel is turning but the hamster is dead.
Craig Kelley  -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: make[3]: *** [ip_masq.o] Error 1
Date: Fri, 22 Dec 2000 21:14:17 GMT



The problem is that the two symbols are defined in ip_masq_mod.h
which is only included if you make IP_MASQUERADING as a module.
Edit the file ./net/ipv4/ip_masq.c and add two lines:

int ip_masq_hash(struct ip_masq *ms);
int ip_masq_unhash(struct ip_masq *ms);

Put these after the #includes but before the EXPORT_SYMBOLs

After I did this, the kernel built and ran fine.

-- Steve




In article <[EMAIL PROTECTED]>,
  Dave Cohen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > I'm trying to build a kernel on a 486-DX2 using source from kernel-
> > source-2.2.16-22.i386.rpm.  The distribution was from RedHat 7.0.
> > The gcc version is 2.96.
> >
> > After about a freakin' hour, it aborts out of the build with the
> > following last gcc text:
> >
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-
prototypes -
> > O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-
> > reduce -m486 -DCPU=486   -DEXPORT_SYMTAB -c ip_masq.c
> > In file included from ip_masq.c:85:
> > /usr/src/linux/include/net/ip_masq.h:319:26: warning: nothing can be
> > pasted after this token
> > /usr/src/linux/include/net/ip_masq.h:322:25: warning: nothing can be
> > pasted after this token
> > /usr/src/linux/include/net/ip_masq.h:325:29: warning: nothing can be
> > pasted after this token
> > ip_masq.c:578: `ip_masq_hash' undeclared here (not in a function)
> > ip_masq.c:578: initializer element is not constant
> > ip_masq.c:578: (near initialization for
`__ksymtab_ip_masq_hash.value')
> > ip_masq.c:579: `ip_masq_unhash' undeclared here (not in a function)
> > ip_masq.c:579: initializer element is not constant
> > ip_masq.c:579: (near initialization for
> > `__ksymtab_ip_masq_unhash.value')
> > ip_masq.c:518: warning: `masq_port_lock' defined but not used
> > make[3]: *** [ip_masq.o] Error 1
> > make[3]: Leaving directory `/usr/src/linux-2.2.16/net/ipv4'
> > make[2]: *** [first_rule] Error 2
> > make[2]: Leaving directory `/usr/src/linux-2.2.16/net/ipv4'
> > make[1]: *** [_subdir_ipv4] Error 2
> > make[1]: Leaving directory `/usr/src/linux-2.2.16/net'
> > make: *** [_dir_net] Error 2
> > [root@pokey linux]#
> >
> > I'm not sure where to start looking.  I would greatly appreciate
some
> > help from the community.
> >
> > Thank you very much.
> >
> > Brian
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> I have the same problem on my P233 system.  Using kgcc is not the
solution
> - although you have to use that  to get the kernel to compile at all.
> Additionally, there is no provision to compile IP masquerading as a
module
> - at least not from xconfig.
>
> Has anyone out there found any additional information?
>
>


Sent via Deja.com
http://www.deja.com/

------------------------------

From: Richard Chase <[EMAIL PROTECTED]>
Subject: Re: kernel questions
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
Reply-To: [EMAIL PROTECTED]
Date: Fri, 22 Dec 2000 21:41:14 GMT

[EMAIL PROTECTED] wrote:

> I have a couple of questions.
> 
> What is a backport?
> 
> What patch goes with what kernel? i.e. Does patch-2.2.18 update kernel
> 2.2.17 or 2.2.18?
> 
> best regards,
> charles

Patch 2.2.18 patches 2.2.17 to make it 2.2.18.

Good luck,
Rich


------------------------------

From: Ulf-Rainer Tietz <[EMAIL PROTECTED]>
Subject: Re: RPC: Connection Refused
Date: Fri, 22 Dec 2000 21:40:16 +0100

[EMAIL PROTECTED] wrote:

> My place of emplyment, someone has devloped a SCSIserver for SGI, SUN,
> and LInux. He used rpc for this. This server program works find on one
> linux box. But when I installed it on a new linux box, I get this 
when I
> use a client: Connection Refused.  I am able to connect fine on the
> other linux box.  I am unable to find any rpc.hosts kind of file any 
on
> the new linux host. What do I need to do on the new linux box to 
accept
> RPC calls?
> 
> thanks
> 
> Enrique Herrera
> [EMAIL PROTECTED]
> 
> 
> Sent via Deja.com
> http://www.deja.com/

You need nfs running 
regards


------------------------------

Date: Fri, 22 Dec 2000 17:03:24 -0500
From: jtnews <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!

I just got a response back from Intel!
Looks like they won't be supporting a Linux driver
for the Easy PC camera.

Anyone know of ANY webcam that works in Linux?

> Hello,
> 
> Intel currently has no plans to provide a Linux* driver for the Easy PC Camera.  
>This is keeping with the target audience, namely, consumers in a home environment who 
>use PCs with Pentium� processors and Windows* 98 or Millennium Edition.
> 
> Information on supported operating systems can be found at 
>http://support.intel.com/support/createshare/camerapack/24595.HTM
> As per this document, any version of Linux* is not supported by Intel� Support.
> 
> Regards,
> 
> XXXXXXXXXXX (name deleted)
> Intel(R) Internet Support
> 
> *Other names and brands may be claimed as the property of others.
> 
> 





jtnews wrote:
> 
> Kaz Kylheku wrote:
> 
> > Of course, unless the Easy PC camera people read this newsgroup, they
> > won't know that. ;)
> 
> I just sent the following message back to Intel support:
> 
> > Any chance Intel will provide a Linux driver for the Easy PC camera?
> > Even if it's just a loadable object module with no source that would
> > be acceptable.  I'd like to use it for my home security system and if
> > they support Linux, I'll buy at least 3 more cameras and recommend the
> > camera
> > in comp.os.linux.advocacy.
> >
> > Can you forward this message over to the Easy PC Camera engineering
> > group?
> >
> > Thanks.

------------------------------

From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Fri, 22 Dec 2000 22:37:50 -0000

On Fri, 22 Dec 2000 17:03:24 -0500, jtnews <[EMAIL PROTECTED]> wrote:
>I just got a response back from Intel!
>Looks like they won't be supporting a Linux driver
>for the Easy PC camera.
>
>Anyone know of ANY webcam that works in Linux?

        I've got a wild idea...

        Howabout typing "Linux" & "webcam" into a search engine.

[deletia]

-- 

        Section 8. The Congress shall have power...
  
        To promote the progress of science and useful arts, by securing for 
        limited times to authors and inventors the exclusive right to their 
        respective writings and discoveries; 
                                                                |||
                                                               / | \

------------------------------

From: Juha Laiho <[EMAIL PROTECTED]>
Subject: Re: Howto access kernel memory from user application ?
Date: 22 Dec 2000 18:53:53 +0200

[EMAIL PROTECTED] said:
>I call query_module (module name, which = QM_SYMBOLS, ...). I get the
>address of the symbol I want to modify = 0xc805246c ; it's exactly the
>address found for this symbol in /proc/ksyms.
>But when I try to read its content (in gdb), I get the message :
>can't access memory at address 0xc805246c.
>
>How could I manipulate this kernel symbol in a user application ?

As far as I understand, kernel memory is accessible only from kernel
mode. All interaction between kernel and user mode is to happen via
system calls.
-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a- C++ UH++++$ UL++++ P+@ L+++ E(-) W+$@ N++ !K w !O
         !M V PS(+) PE Y+ PGP(+) t- 5? !X R tv--- b+ DI? D G e+ h--- r+++ y+
"...cancel my subscription to the resurrection!" (Jim Morrison)

------------------------------

From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Problems with Linux kernel?
Date: 22 Dec 2000 23:29:38 GMT

In article <[EMAIL PROTECTED]>, Erik de Castro Lopo wrote:
>mitch@foo wrote:
>> 
>> In article <OsA06.85260$[EMAIL PROTECTED]>, "Joshua says...
>> >
>> >I want to hear peoples' voices and opinions about what programmers do and
>> >don't like about the Linux kernel.  All feedback will be integrated into the
>> >design of yet another Open Source operating system.
>> 
>> Is this a joke?
>> 
>> instead of re-inventing the wheel one more time, why don't
>> you spend the effort to improve what is allready here?
>
>I think you missed the point. Here's a translation:
>
>"I want to write a operating system kernel but can't think of
>a simngle good reason to do so. Can You?"
[-]

Just the kind of people with which we'd still live in caves
as they're working fine after all.

------------------------------

From: Keith Hulse <[EMAIL PROTECTED]>
Subject: VFAT problems with Kernel 2.2.18
Date: Fri, 22 Dec 2000 23:30:04 -0000

Hi, I am relatively new to Linux and I have a problem after compiling the 
new 2.2.18 kernel. My floppy, zip, and Windows drives (yes I am running 
Win98 as well!) are not mounted. The message I get is along the lines of: 
These file systems are not supported by 2.2.18.

The kernel is compiling autofs and using it but I don't know where to go 
next. Can anyone help.

Keith Hulse

--
Posted via CNET Help.com
http://www.help.com/

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy,alt.linux.sux
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Reply-To: [EMAIL PROTECTED]
Date: Sat, 23 Dec 2000 00:36:15 GMT

On Fri, 22 Dec 2000 17:03:24 -0500, jtnews <[EMAIL PROTECTED]>
wrote:

>I just got a response back from Intel!
>Looks like they won't be supporting a Linux driver
>for the Easy PC camera.
>
>Anyone know of ANY webcam that works in Linux?
>
>> Hello,
>> 
>> Intel currently has no plans to provide a Linux* driver for the Easy PC Camera.  
>This is keeping with the target audience, namely, consumers in a home environment who 
>use PCs with Pentium� processors and Windows* 98 or Millennium Edition.
>> 
>> Information on supported operating systems can be found at 
>http://support.intel.com/support/createshare/camerapack/24595.HTM
>> As per this document, any version of Linux* is not supported by Intel� Support.
>> 
>> Regards,


Translation: There isn't enough of a Linux home desktop market to make
it worth their while. 
And until Linux can prove it is at least as good as Windows in that
application there never will be a desktop market for Linux. 



Flatfish
Why do they call it a flatfish?
Remove the ++++ to reply.

------------------------------

Date: Fri, 22 Dec 2000 18:45:33 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: libc vs glibc and posix

[EMAIL PROTECTED] wrote:
> 
> I have been looking all over for this answer, but  i am out of luck.
> from a programmers perspective, what is the difference between libc5 and
> glibc?  for ionstance, what type of code coould i compile under glibc
> that i couldn't under libc5?  the only thing that i could find was some
> headers (errno.h) had to be explicitly called, and that signals are more
> BSD than SRV.  are there anyu other differences, or does anybody know
> any docs which explain the differences?
> 
> thank you....
> 
> Sent via Deja.com
> http://www.deja.com/

I'm not positive to what extent it applies, but much of glibc has
reentrant or otherwise threadsafe versions of functions that can be
used, whereas this was virtually non-existent in older libc5.

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: front ending libraries (even libc)
Date: Sat, 23 Dec 2000 04:59:25 -0000

On Fri, 22 Dec 2000 05:33:33 GMT Joe Bob <[EMAIL PROTECTED]> wrote:

|> I'm starting to take a look at what might be needed to do library front
|> ending.  What I mean by that term is this.  An existing library, such as
|> libc, will have a complete set of its own functions.  The front ending
|> library will have a subset of the functions (possibly just a few, maybe
|> even just one).  I want to have, AT RUN TIME, for the front end library
|> to be preferred over the back end library for dynamic linkage.  If the
|> symbol is defined in the first library found, use that.  But if it is
|> found not in the first, but in the second, use that.  There needs to be
|> not conflict with respect to the fact that the second library also has
|> the same symbols found in the first.  I'm thinking of the first library
|> as a sort of mask layed over the second, hiding some symbols and having
|> its own versions of them instead.
|
| I just had the occaision to do this today.  My goal was to override a libc
| function with my own version.
| Just write your replacement function (namespace, returns and arg casting the
| same!).  Link it into your own shared
| library.  Set the LD_PRELOAD variable at run time; export
| LD_PRELOAD=/usr/local/lib/libspecial.so.  Then
| start your app.  Its just that easy.  You can confirm that your dynamic
| library is getting used by doing a "ldd" on your
| binary.

OK, now how can I get my special function to turn around and call the real
one in libc, without calling itself in a loop?  This would be so that I do
not have to fully re-implement that library function, but just make a front
end to wrap it's calls.  Would I have to dlopen("/lib/libc.so.6",RTLD_NOW)
and dlsym(dlhandle,"readdir") to make that call (for readdir() in this case)?
Or is there a way to do it by linking if there is no alternate symbol name
(some functions do have __alternate names and some do not)?  Will dlopen()
reuse the mapping or the library that was used by ld.so or make a new one?
The man page for dlopen says 2 calls to dlopen() for the same library will
return the same handle, so I assume the same mapping will be involved in
that case, but it doesn't say anything about doing dlopen() for a library
which is already mapped and linked by ld.so.  If ld.so is doing all its work
via the same dlopen() then I guess this would be OK.

-- 
=================================================================
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/     |
=================================================================

------------------------------

From: Tim Roberts <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Intel Easy PC camera - cannot be supported in Linux!
Date: Fri, 22 Dec 2000 21:42:55 -0800

jtnews <[EMAIL PROTECTED]> wrote:
>
>What I don't understand is why a company as big as Intel won't support
>Linux, even if it was just a driver with an object file and no source,
>that would do.  I'd like to use the Easy PC camera as a home security
>intrusion detection camera.  If they made the driver available for
>Linux, then I'd buy at least 3 more cameras.

Big deal.  Individual consumers don't mean a thing in that market.  The way
Intel makes money with their cameras is by shipping them to OEMs who bundle
tens of thousands a month with their computers.  When IBM or Dell or Compaq
threatens to go to another vendor because Intel has no Linux driver, then
you can bet there will be a Linux driver within the month.  That isn't
going to happen for a while yet.

I've worked with some of the Intel PC Camera engineers.  They are, indeed,
doing some moonlight work to create Linux drivers for the cameras.  But
much of the problem is in Linux: it still lacks a coherent multimedia
infrastructure.  The first problem you have to solve is USB: isochronous
USB transfers (which all the PC Cameras use) are a relatively recent
addition to Linux, and I'm not sure they're reliable even now.

What kind of driver would you write?  In the Windows world, you can open up
a DDK and say, "HERE is the way you write a capture driver with a still
image interface.  HERE is the way you hook into the imaging filter stream
for DirectShow."  You write a driver, you test it with VIDCAP and AMCAP and
Premiere. and you have 99.99% confidence that it will work with every other
video capture application written for Windows.  There is no such single,
identifiable standard in Linux.  You can't pick out a program X and say,
"if it works with X, it will work with any camera application."

It will happen some day, as more and more desktops migrate, but Linux is
still way behind in this area.

I'm climbing into my flame-proof suit now.
--
- Tim Roberts, [EMAIL PROTECTED]
  Providenza & Boekelheide, Inc.

------------------------------


** 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
******************************

Reply via email to