Linux-Development-Sys Digest #889, Volume #6 Sat, 26 Jun 99 06:13:56 EDT
Contents:
Re: Why not C++ (John E. Davis)
Re: Why not C++ (John E. Davis)
tcp port no.s vs. processes (Sudip Sarbajna)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Craig Kelley)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Craig Kelley)
IP Masq module for directplay? (Jason Baker)
Wield system, X11 glibc2 or egcs1.1.2 broken? (y chen)
memcpy from mmap'ed buffers (Nitin Malik)
Re: tcp port no.s vs. processes (Tuomas M��tt�nen)
Re: Why not C++ (Andi Kleen)
Re: gcc byte packing of inherited class data (BOIRIE Gregor CNAM 98-99)
Re: Parameters in kernel 2.2.x modules ("B. James Phillippe")
Re: using C++ for linux device drivers (Justin Vallon)
Re: Why not C++ (Justin Vallon)
Re: Why not C++ (Justin Vallon)
Re: TAO: the ultimate OS ("Anonymous")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 04:56:06 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 26 Jun 1999 11:53:08 +1200, Bruce Hoult <[EMAIL PROTECTED]>
wrote:
> some_function(&foo);
>
>What will be foo's value after the call to some_function? Will it be
>altered? In C he has no way of knowing because C programmers often pass
>structs by reference even when they don't intend to change them.
At least the syntax indicates whether or not foo could be altered.
The fact remains that one cannot look at
some_function (x)
in C++ and be sure that x was not modified, whereas in C you know that
the local variable x will not be affected. And yes, like many people,
I use an editor that supports tags. When reading C++ code, I do have
to look up every such function to see whether or not something like x
could be modified by the function. With C, knowing instantly that x
could not be modified is a big help to understanding code fragments.
--John
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 05:28:49 GMT
Reply-To: [EMAIL PROTECTED]
On 25 Jun 1999 09:50:23 -0700, Don Waugaman <[EMAIL PROTECTED]>
wrote:
>Reference semantics can be abused, true. Of course, would you really
>feel comfortable reading this code and not knowing a thing about what
>some_function() does?
It depends upon the situation. When trying to find a bug in code that
I am not familiar with, it is important to me to know what is
happening to local variables. In C++, you can never be sure about
local variables in the presence of function calls because of the
possibility of reference variables. By not having references, it is
easy to deduce some basic information by looking at code fragments,
e.g.,
s = "silly example";
n = strlen (s) - 1;
for (i = 0; i < n; i++)
{
x += some_function (i, s[i]);
s++;
}
If the language is C, then I can be sure that this loop executes n
times (assuming no longjmp). After the loop, I know that `i' will be
`n' and `s' will be pointing at `e'. With C++, one simply cannot make
these basic observations without knowing the definition of `some_function'.
--John
------------------------------
From: [EMAIL PROTECTED] (Sudip Sarbajna)
Subject: tcp port no.s vs. processes
Date: 26 Jun 1999 05:35:58 GMT
Hi
I am facing a challange where I need to get a listing of "tcp port no.s vs.
processes" in a running system.
I am looking for an existing utilty(command) which could do this
OR
I am ready to write the utility myself( if it does not exist already).
But I am lacking knowledge in what system calls to make and what are they going
to do.
Can anybody help me out in this matter?
Again, my objective is to administer(i.e. to list - the 1st. step!) the
processes
running in a system that are listening to some port( hence the port no. in the
list)
Any help and pointer to this issue will be highly appreciated.
Thanks in advance.
Sudip
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
From: Craig Kelley <[EMAIL PROTECTED]>
Date: 25 Jun 1999 23:31:05 -0600
[EMAIL PROTECTED] (Terry Murphy) writes:
> The two advantages I see in the registry are:
>
> (a) programmatically writable
> (b) uniform tool/file format/routines for all programs
> (c) inherent error checking (by way of types)
Those can all be done with some library *over* text files.
The best of both worlds (look at the samba code sometime).
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
From: Craig Kelley <[EMAIL PROTECTED]>
Date: 25 Jun 1999 23:27:05 -0600
[EMAIL PROTECTED] (Terry Murphy) writes:
[welcome back Terry :) ]
> >It would be rather more fair to compare regedit, weighing in at 71K, with
> >something like t.exe, which weighs in at 1K.
>
> I do not know what t.exe is, but assuming it is a small text editor,
> there is no reason you could not implement a very small registry
> editory, since there are calls to do all of the real work.
>
> At the minimum all you need is code to change a value, see the values,
> and get the keys. These are INHERENTLY simpler operations, and could
> be implemented with less code than it would take to implement a general
> purpose text editor which can perform the operations as efficiently.
But vi is already written.
And ported to Win32.
Where's my bootable NT disk with a registry editor?
> My problem with this thinking is that you are only referring to the
> Windows implementation of the registry. I am merely advocating
> database configuration systems in general, and there's no reason
> that one couldn't handle this stuff.
So build it...
(after all, it's "easy" to do, right?) :)
--
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: Jason Baker <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: IP Masq module for directplay?
Date: 26 Jun 1999 00:30:39 GMT
Does anyone know of a team that's working on an ip_masq module for
directplay/directx? I've set up a NAT/IP Masq box for some friends, and
they love it with the exception that only one of them can easily play
directplay based games on external servers at a time.
Alternatively, pointers on how to start development of such a beastie would
be appreciated.
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: y chen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Wield system, X11 glibc2 or egcs1.1.2 broken?
Date: Fri, 25 Jun 1999 23:19:01 -0400
Hello, there,
I find my box is very wield, hopely I can get advice here.
I have a slackware 3.6 box, with libc.so.5.46 and glibc2.0.7
as test library. I had MIT pthread installed, and I can do
pthread home work wothout any problem.Everything was well
until I would like pthread programming in X , I mean, put these
two together.
So I installed egcs-1.1.2 and binutil 2.9, then glibc2.1.1
At this point, my system goes very well. I recompiled
kernel and it is stable.
Then I compiled X3331 and windowmaker0.60.0.
Now, I can run windowmaker, but when I run a small piece
of X program, it segment fault in xterm, but I can run it in
gdb. ( this is very wield, isn't it?)
Another wield thing is I compiled a small piece program
doesn't require X and pthread. When I run it, It said libXext
can not be found. Finally it found it(2), it seg fault.
So any advice will be highly apreciated. Which part of my
system is broken, glibc2, libX or compiler egcs or ld?
I can not figure it out.
Some clues I think are useful:
(1) gcc draw.cxx -lX11 doesn't work, I should
gcc -L/usr/X11R6/lib -lXext -lX11 draw.cxx.
(2) I must put /usr/X11R6/lib in LD_LIBRARY_PATH
otherwise, a.out won't run.
------------------------------
Date: Sat, 26 Jun 1999 00:43:10 -0400
From: Nitin Malik <[EMAIL PROTECTED]>
Subject: memcpy from mmap'ed buffers
I have mapped the DMA packet receive buffers (located on host memory) to
the user space to implement a single copy packet reception scheme.
Thus the user application just copies the data from the DMA buffers to his
buffers... To read 10000 bytes of data, the time taken is approx 475
microsec, which is much larger than the time in the original TCP/IP scheme
(220 microsec).
Since the MTU for ethernet is 1460, max data size per packet is 1460. This
memcpy operation takes around 70 microseconds.
For 10000 bytes, the total memcpy operation takes 400 microsec... this
doesn't make sense, as the original scheme does a memcpy across the
user-kernel boundary and still manages to do the whole memcpy faster.
Why is this abnormal time for memcpy? Is it because of some special access
checks to read the device buffers? But I thought all these checks will be
avoided due to the mmap operation... so the memcpy shud be as though it
were occuring in the user space... which takes 25 microsec per 1460 bytes.
Someone please assist me in this problem...
Thanks,
nitin
------------------------------
From: Tuomas M��tt�nen <[EMAIL PROTECTED]>
Subject: Re: tcp port no.s vs. processes
Date: 26 Jun 1999 10:10:51 +0300
[EMAIL PROTECTED] (Sudip Sarbajna) writes:
> I am facing a challange where I need to get a listing of "tcp port no.s vs.
> processes" in a running system.
You are probably looking for lsof(8). lsof -i TCP produces something
like this:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 152 root 4u inet 60 TCP *:sunrpc (LISTEN)
inetd 163 root 4u inet 67 TCP *:discard (LISTEN)
inetd 163 root 6u inet 69 TCP *:daytime (LISTEN)
/* Tuomas M��tt�nen <[EMAIL PROTECTED]>
* Finland Bored with yourself? Want a new personality?
* Call 1-800-PSICORP.
*/
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 06:53:38 +0200
[EMAIL PROTECTED] (Greg Comeau) writes:
> In article <7kscsl$s0h$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nathan Myers)
>writes:
> >Ralph Glebe <[EMAIL PROTECTED]> wrote:
> >> Are all the programs in C because: [speculation]
> >
> >There are quite a lot of C++ projects on Linux. C projects (still)
> >outnumber them for several reasons.
> >
> >1. C is an easier language to learn to use fully, so you may get
> > better participation on a C project because you're drawing on
> > a larger population.
>
> This is a nit, and one I believe Nathan will agree with, but IMO,
> it's not an easier language as much as it's perceived to be an
> easier language. I mean, sure, C syntax is definitely smaller than
> C++ syntax and such. But C programming involved more than just that
> since a C programmer still has to learn general techniques, etc.
> Also, even specific to C, I find the average C programmer does not
> know C well. Probably fair to say that they more or less know some
> subset enough to get by. Anyway, the bottom line is the C is popular
> and will remain so.
Well, the theory is that:
int f(vector<vector<float> > array)
is easier than
int f(float **array)
to handle for a beginner. The praxis is that what the C++ compiler
presents you as error message for a slight in template related
stuff is just horrible, and I wouldn't want to decipher that as
newbie[1].
-Andi
[1] This is mainly for egcs, I don't know if other C++ compilers
produce better template-related error messages.
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (BOIRIE Gregor CNAM 98-99)
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: Re: gcc byte packing of inherited class data
Date: 26 Jun 1999 07:26:16 GMT
Bruce Edge ([EMAIL PROTECTED]) wrote:
: Stefan Seefeld wrote:
: >
: > Bruce Edge wrote:
: > >
: > > I can't get gcc to pack this data:
: > >
: > > class a
: > > {
: > > char c;
: > > };
: > >
: > > class b
: > > {
: > > long l;
: > > };
: > >
: > > class c : public a, public b
: > > {
: > >
: > > };
: > >
: > > Without going into why I need a misaligned long after a char,
: > > I need the alignment for class c to be:
: > >
: > > cc ll ll ll ll
: > >
: > > not:
: > >
: > > cc xx xx xx ll ll ll ll
: >
: > given your requested alignment, how would you expect a cast from
: > (c *) to (b *) to work ? It doesn't give a valid address.
:
: I admit to being new to linux programming, but I'm not sure what you
: mean by a valid address, are you referring to having a long on a
: misaligned
: boundry?
: This works on QNX.
:
: -Bruce.
------------------------------
From: "B. James Phillippe" <[EMAIL PROTECTED]>
Subject: Re: Parameters in kernel 2.2.x modules
Date: 26 Jun 1999 08:03:07 GMT
On Fri, 25 Jun 1999, Manuel Santos wrote:
> I'm porting my own device driver module for the data adquisition card
> ACL-8112 from kernel 2.0 to 2.2. I want to pass parameters to the module
> in load time, but I've heard that this has changed in the new kernels.
>
> Can anyone tell me how can I do it?
Sure, it's pretty easy. There are macros defined that look like this:
MODULE_PARM(variable, "format");
MODULE_PARM_DESC(variable, "description of option");
Here's an example:
static int io_addr[4] = { 0, };
MODULE_PARM(io_addr, "1-4i");
MODULE_PARM_DESC(io_addr, "List of IO ports to probe for mydevice");
Look at include/module.h for details on how these and other MODULE_* macros
work.
cheers,
-bp
--
# bryan at terran dot org
# http://www.terran.org/~bryan
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 26 Jun 1999 03:42:18 -0400
Mario Klebsch <[EMAIL PROTECTED]> writes:
> Justin Vallon <[EMAIL PROTECTED]> writes:
>
> >Mario Klebsch <Mario [EMAIL PROTECTED]> writes:
>
> >> Justin Vallon <[EMAIL PROTECTED]> writes:
> >> >These are not C++-ish. There are completely reasonable
> >> >implementations of ::operator new and ::operator delete in terms of
> >> >the C memory allocator. Why do you require anything more complicated?
> >> >If malloc doesn't do a good job, then malloc should be re-written.
> >>
> >> Hey, we are in comp.os.linux.development.system!!!
> >> ^^^^^^
> >>
> >> And we are talking about kernel code. AFAIK, there is no malloc in
> >> the kernel. So you have to do something yourself.
>
> >From what I understand, it would be to use kmalloc.
>
> Yes, and how to you tell the compiler to use kmalloc instead of malloc?
> Having ::operator new and ::operator delete seems to be the right tool
> for me.
Correct. The standard C++ library would most likely define ::operator
new and ::operator in terms of malloc and free. Since the standard
C++ library would not be available, those runtime support functions
must be defined (as part of C++ kernel runtime support), and their
definitions would be to use the kernel's memory management.
In other words:
void *::operator new(size_t s) { return kmalloc(s, GFP_KERNEL); }
void ::operator delete(void *p) { kfree(p); }
I think we are agreeing here. No?
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 04:00:08 -0400
David L. Bilbey <[EMAIL PROTECTED]> writes:
> +-----On 24 Jun 1999 17:02:09 -0400, Stefan Monnier spoke unto us:----------
> | >>>>> "Ralph" == Ralph Glebe <[EMAIL PROTECTED]> writes:
> | > [...]
>
> | Wring question. The question should be:
>
> | Why C++ ?
>
> - Objects
> - Inheritance
> - Polymorphism
> - Overloaded functions/operators
> - Streaming I/O
Abstraction
Public interfaces
Protocol classes (virtual bases)
Design patterns: Factories, etc
And, yes, of course, you could write Linux in Common-Lisp, or OO in C.
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 04:03:33 -0400
[EMAIL PROTECTED] (Greg Comeau) writes:
> In article <7kscsl$s0h$[EMAIL PROTECTED]> [EMAIL PROTECTED]
> (Nathan Myers) writes:
> >2. It takes substantial extra effort to code C++ libraries that are
> > binary-compatible from one release to the next, so library version
> > problems are incrementally harder.
>
> This is definitely a roadblock, but I wonder how many people actually
> realized this when they started out? I would suspect not to many.
> Luckily Standard C++ is out and at least for now binary compatible issues
> are known and can be addressed by compiler implementors as they upgrade.
> Of course, some compilers have done this more than others. :)
Why would binary compatibility between compiler releases be an issue
for the kernel? Don't you build the entire kernel under one compiler?
Maybe for modules, but you'd extern "C" those, anyway.
Or, are you speaking in general (libnifty.1, libnifty.2)?
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: "Anonymous" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 12:54:50 GMT
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
> revealing another bias that merely being concerned with the UI is
> the realm of those who deal with users.. bzzzzzzt.. everyone designing
> the OS, from top down, needs to be concerned with user requirements.
> some very highlevel requirements (e.g. need to be virus proof)
> are driven by user demand.. & just good sense
No they don't. Despite your idealism, those who have no idea how end-users
use computers will proliferate through their competency in other areas.
It's called specialization.
> : The founders of Linux do not design the UI and I'm glad that they
aren't
> : stuffing the OS core with such peripheral, however central to end-user
> : computing experience, parts.
>
> I am asserting the point that the entire OS and not merely the UI
> needs to be reoriented around the user..
A moot point. Such reorientation (referring to your original article for
now) of course breaks nearly all compatibility channels and introduces
unacceptable performance penalties at the OS level; no that's not what a
user wants. The reason why an OS is kept as primitive (um, excuse me) as it
is that fancy featurism is not welcome on a general purpose system. If I'm
not going to use a certain feature, why should I pay a performance penalty
for it? Taking this to an extreme you get exokernel Operating Systems.
> I believe an attempt to
> put a friendly GUI on linux will ultimately fail in the long run
> to achieve ease-of-use or end-user-friendly goals.. but not
> very soon. its a dead end I don't think will be recognized for many
> years. this is not to say the GUI work is being wasted. it could
> be used on top of another OS.
Life is a dead end. We all ultimately die.
> : You cannot dumb down a computer below a certain level without
sacrificing
> : its functionality.
> moot point. the computer can demonstrably simplified tremendously
> beyond what unix supplies users.
Perhaps it's about time for you to "demonstrate" it? Computer's highest
functionality is its programmability and there's no way to use it, other
than through programming. A computer cannot do anything more than what it
is told to do (predictably, that is) and an OS programmer cannot be
expected to program every possible thing that you might want to do. The
logical step, then, is programmable interface (Unix shells/programming
tools). Alternatively, you could have tools that take ambiguous input
(still in premature development), but I'd rather tell a computer exactly
what I want than have it guess I want.
------------------------------
** 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
******************************
