Linux-Development-Sys Digest #976, Volume #7 Mon, 26 Jun 00 01:13:11 EDT
Contents:
Kdevelop prevede classi C++ o Java x interfacciarsi ai DBMS? ("MASSIMO DA ROS")
Re: Packaging for Release (J.H.M. Dassen (Ray))
Re: bootlogos (Dennis Schoen)
Re: how to find the cpu clock frequency? (x86) (Nix)
Re: running remote untrusted code (Tramm Hudson)
Re: how to find the cpu clock frequency? (x86) (David Wragg)
pthreads and memory access (HELP!!) (Adam Majer)
Re: 64bit division (Aki M Laukkanen)
Re: Alan Po Again. How to start to study the KERNEL of Linux ("Phillip Soltan")
Re: How to program/write a new filesystems into the kernel? (OSguy)
Multi-threaded Device drivers ?? ("ELSID Software Systems LTD.")
setting icmp_echoreply_rate & others in /proc? (John Hovell)
----------------------------------------------------------------------------
From: "MASSIMO DA ROS" <[EMAIL PROTECTED]>
Subject: Kdevelop prevede classi C++ o Java x interfacciarsi ai DBMS?
Date: Sun, 25 Jun 2000 09:58:18 GMT
Ciao a tutti ..
volevo sapere se Kdevelop prevede classi C++ o Java x interfacciarsi ai DBMS
grazie a tutti
Massimo
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: Packaging for Release
Date: Mon, 19 Jun 2000 22:19:44 +0200
Avi Shmidman <[EMAIL PROTECTED]> wrote:
>The question now is, how should we distribute this? Should we use the
>redhat RPM scheme, or will that help only redhat users?
RPM is used by other distributions as well (e.g. SuSE, Mandrake), but that
doesn't mean one RPM will work on all these distributions. I'd recommend
using a simple source tarball.
>Should we provide the source of the device driver,
If possible, yes. The kernel developers have stated that they will not take
compatibility with binary-only drivers in consideration when making changes
to the kernel. Thus, a binary-only driver is of limited value and many users
stay away from them.
>or just of the user mode API? Should we provide executable examples
>programs, or just source?
Personally, I don't care much for executables, but it can't hurt to provide
them. For me source, together with clear instructions on builing it, is much
more important.
HTH,
--
Ray Dassen <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Dennis Schoen)
Subject: Re: bootlogos
Date: Sun, 25 Jun 2000 13:39:01 +0200
Reply-To: [EMAIL PROTECTED]
On Sat, 24 Jun 2000 21:09:47 GMT, Spehro Pefhany <[EMAIL PROTECTED]> wrote:
>The renowned Dennis Schoen <[EMAIL PROTECTED]> wrote:
>
>> When you want to change it, have a look at
>> http://home.sol.no/~dvedoy/
>
>Any hints for those of us who are limited to english ?
>This appears to be in some Scandanavian language, Norse, I'd presume.
Huh, the page is in english when i look at it.
Dennis
--
| Dennis Schoen | "Contrary to popular belief,
| [EMAIL PROTECTED] | UNIX is a user-friendly Operating
| http://www.gt.owl.de/~dschoen/ | System. It's just choosey about
| +49-5207-923701 | who its friends are."
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: how to find the cpu clock frequency? (x86)
Date: 25 Jun 2000 12:54:58 +0100
Gary Funck <[EMAIL PROTECTED]> writes:
> Hello, on a Pentium Pro system, I want to use the RDTSC instruction to
> read the cycle counter to perform some low level time stamping. I'd
> like to convert those time stamps back into wall clock time, and
> therefore need to know the cpu clock frequency, in a reasonably portable
> way.
The kernel does all of this already. On a system with a TSC and the
RDTSC instruction, gettimeofday() is accurate down to the limits of its
resolution thanks to the TSC.
There are also kernel patches out there to let you read the RDTSC down
to the limits of *its* resolution, in non-wall-clock form. Search an l-k
mailing list archive and you should find them. They were last posted
about half a year ago, IIRC.
--
`I can guarantee it's no problem in my network, and if I don't get some
sleep soon, I'll guarantee it will become a problem in your network.'
--- Chris `Saundo' Saunderson deals with a late-night phone call
------------------------------
From: [EMAIL PROTECTED] (Tramm Hudson)
Subject: Re: running remote untrusted code
Date: 25 Jun 2000 16:06:20 GMT
[posted and cc'd to cited author]
Kari Pahula suggested:
> You can pass -nostdlib to the linker to disable any standard
> libraries, and use ptrace to any suspicious binaries to make sure they
> don't link any unwanted libraries....
and Brennan Cheung <[EMAIL PROTECTED]> responded:
> How could virii be a problem if there is no file access or IPC? They will
> not have any access to anything except the processor and my API.
How do you propose to not give them any file access? Just because
they do not link to libc does not prevent them from opening files
as this little snippet of code will show:
int open_with_nostdlib( void )
{
long fd;
__asm__ volatile ("int $0x80"
: "=a" (fd)
: "0" (5 ),
"b" ((long)( "/etc/passwd" )),
"c" ((long)( 2 )));
return fd;
}
who needs the standard library to open files in a non-portable
fashion? I think that you might be underestimating the ability
of programmers to get outside of your API with very little effort.
And what exactly is a "virii"? Didn't you see the whole debate on
/. about using Latinized plurals on non-Latin nouns?
Tramm
--
o [EMAIL PROTECTED] [EMAIL PROTECTED] O___|
/|\ http://www.swcp.com/~hudson/ H 505.323.38.81 /\ \_
<< KC5RNF @ N5YYF.NM.AMPR.ORG W 505.986.60.75 \ \/\_\
0 U \_ |
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: how to find the cpu clock frequency? (x86)
Date: 25 Jun 2000 14:15:32 +0000
Gary Funck <[EMAIL PROTECTED]> writes:
> One way, I think, to get the cpu cycle time is read /proc/cpuinfo, and
> parse the field that gives the cycle time. Is there something more
> direct? Same question for determining the type and capability of the
> cpu.
Reading /proc/cpuinfo is by far the simplest way. The 2.4.0
pre-releases have recently added a cpuid device, which reveals the
results of the CPUID instruction directly, but it will be a long time
before that is as widely supported as /proc/cpuinfo.
The official way to check for TSC support is using the CPUID
instruction. This needs a fair bit of assembly, once you include the
check for CPUID support.
Another apporach would be to simply try a rdtsc. If you get an illegal
instruction exception (caught by an appropriate signal handler) with
EIP pointing to the rdtsc, then it isn't supported.
David Wragg
------------------------------
From: Adam Majer <[EMAIL PROTECTED]>
Subject: pthreads and memory access (HELP!!)
Date: Sun, 25 Jun 2000 12:04:51 -0500
Hi all,
Here at U of M, we have an 8-processor computer. It has about 3G mem
with 30M shared. I have transfered some of the programs from a fork
(create the same process with _everything_ in it - libs, data, etc.) to
a thread using the pthread library. Each of the threads uses a
substatial amount of memory (>16M). Unfortunatelly, ALL of the memory
that is accessed by pthreads is only in the shared memory area. So,
most of the time, the CPU appears to be swapping from the shared memory
to the non-shared and not doing the calculations that each thread is
doing.
My question would be how to make sure that all of the memory accessed is
by default in the non-shared area instead of the shared memory pool?
Thanks for any help in advance,
Adam
------------------------------
From: [EMAIL PROTECTED] (Aki M Laukkanen)
Subject: Re: 64bit division
Date: 25 Jun 2000 19:44:33 GMT
In article <[EMAIL PROTECTED]>, Nix wrote:
>__divdi3 would seem a better name, all things considered. GCC knows
>about that name, after all.
You didn't read. If __divdi3 was accepted then kernel could link
with libgcc just aswell. Making the division explicit should give
confirmation that the programmer really knew what he was doing and
accepted the consequences.
--
D.
------------------------------
From: "Phillip Soltan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.hardware
Subject: Re: Alan Po Again. How to start to study the KERNEL of Linux
Date: Sun, 25 Jun 2000 20:56:15 GMT
I hope your doing this as a learning experience or for fun. According to
the RedHat site, Linux has a practical lower limit of a couple hundred
thousand bytes of RAM, which is too much for some embedded applications.
They sell support for a freely downloadable embedded OS with networking call
ECOS. You might want to take a look at it before you try and turn Linux
into an embedded OS.
Phil Soltan
Alan Po wrote in message <8i0av0$[EMAIL PROTECTED]>...
>Dear all!
>
>Alan again, the University student who need to write an embedded Linux.
>Before to start my project, I want to know more about the design and
>structure of Linux Kernel. Is there any good reference on the web or books?
>I have found a web which is the Linux Documentation Project (LDP) but I
want
>to know more. Please give me some suggestion and recommendation.
>
>Thanks a lot,
>
>Alan Po
>[EMAIL PROTECTED]
>
>
>
>
------------------------------
From: OSguy <[EMAIL PROTECTED]>
Subject: Re: How to program/write a new filesystems into the kernel?
Date: Sun, 25 Jun 2000 17:41:55 -0500
learner wrote:
> Forgive the dumb question I'm about to ask, but I've been searching
> around for a while, and just haven't seen anything on this topic.
OK, I found O'Reilley's book on Linux Device Drivers and it appears to have
the info I was looking for. Sorry for the dumb question.
------------------------------
From: "ELSID Software Systems LTD." <[EMAIL PROTECTED]>
Subject: Multi-threaded Device drivers ??
Date: Sun, 25 Jun 2000 21:18:20 -0700
Greetings:
Is it possible to create an independent thread within a device driver
and if so can someone point me at an example.
Regards,
Robert
[EMAIL PROTECTED]
------------------------------
From: John Hovell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,linux.dev.kernel,linux.sources.kernel
Subject: setting icmp_echoreply_rate & others in /proc?
Date: Mon, 26 Jun 2000 02:27:53 GMT
hello all --
I was wondering if any of you knew if there is something special you
need to compile into the kernel (running 2.2.15) for features like
icmp_echoreply_rate and friends to work.
I have set each to "1" (the lowest integer value) ... something that is
a mesure in "jiffies" - AFAIK, 1 jiffie for x86 = 10 ms.
Soo... it would appear that the _lowest_ rate of icmp echo replies can
be set to is 100 per second (which is no good in and of itself...
nevertheless...).
Just the same, using the traditional flood ping from localhost or
ethernet from another machine, I am logging 10 times this number or more
(1000 to 2000 packets a second)...
Was there something I had to compile in for this to work??
There's not much kernel doc. i can find on this subject. this is what
is said:
icmp_destunreach_rate - INTEGER
icmp_paramprob_rate - INTEGER
icmp_timeexceed_rate - INTEGER
icmp_echoreply_rate - INTEGER (not enabled per default)
Limit the maximal rates for sending ICMP packets to specific
targets.
0 to disable any limiting, otherwise the maximal rate in
jiffies(1)
See the source for more information.
What is the source file?? I guess I am dumb, but I have looked in all
sorts of sysctl.h files and can't find anything referencing these
features.
TiA for any info...
Cheers,
John
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
John Hovell Tel: (650) 497-1982 x1
PO Box 17968 Fax: (520) 447-1965
Stanford CA, 94309 Cel: (203) 223-8654
PGP Key: http://www.stanford.edu/~jhovell/pgp
Homepage: http://24.228.17.102/
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
------------------------------
** 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
******************************
