Linux-Development-Sys Digest #877, Volume #7 Fri, 19 May 00 04:13:14 EDT
Contents:
Re: linux kernel not C++ friendly? (Grant Edwards)
Re: serial port RTS control ? (Grant Edwards)
Re: linux kernel not C++ friendly? ("Ross Smith")
Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
Re: #include <linux/sched.h>
Re: Linux Mutexes and Conditions & 2.3.99 (Kaz Kylheku)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: Need ideas for university funded project for linux (David Steuber)
Re: Need ideas for university funded project for linux ("Peter T. Breuer")
Re: linux kernel not C++ friendly? ("Mikko Jaakkola")
Re: linux kernel not C++ friendly? (Matthew Palmer)
Re: does linux support RAMDISK??? (Josef Moellers)
Re: does linux support RAMDISK??? (Bernd Strieder)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: linux kernel not C++ friendly?
Date: Fri, 19 May 2000 03:14:47 GMT
On Fri, 19 May 2000 02:09:14 GMT, Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>>> Thus leading me to wonder, if a kernel module could not be developed using C++
>>> classes and structures?
>>Short answer: No.
>>
>>Medium sized answer: You could, but you'd have to provide all the
>>run time support usually provided by C++'s support libraries, and
>>libc. You don't want to do this.
>
>I see. So it follows that to use C for writing kernel code,
>you would also need to provide all the run time support normally
>provided by a hosted implementation of C.
Some of it. printk(), kmalloc(), and so on have already been
written, so you as a driver writer don't have to impliment libc
replacements. If you wanted to use C++, there might be things
that you would have to impliment.
--
Grant Edwards grante Yow! I'm wearing PAMPERS!!
at
visi.com
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: serial port RTS control ?
Date: Fri, 19 May 2000 03:18:05 GMT
On Thu, 18 May 2000 23:57:48 +0200, Fred <[EMAIL PROTECTED]> wrote:
>> This will not work as expected, since the second ioctl() does not wait
>> until all data is send. In fact, the entire "Hello World\n" and even
>> much more, will fit into the device output queue. So you probably
>> will have a little spike on RTS and the data wil be shifted out of TxD
>> after that spike, when RTS is inactive. :-(
>
>I guess there is no function to flush the data before to clear RTS ?
Not in a manner useful to this discussion. The drain ioctl()
call only waits until the last of the data has been written to
the UART.
>> You have to do some waiting prior to releasing RTS. Waiting for the
>> output Queu to empty is not that hard, especially for kernel level
>> code. The next step is to wait for the internal FIFO of the UART to
>> become empty and after that, (now the last character is in the output
>> shift register), you still have to wait until the stop bit is output
>> on TxD. For this last delay, I had to use polling, and this is ugly.
And on some UARTs the shift register empty status bit goes true
before the stop bit is sent.
>humm, it's what I guess :-(
>
>> OTOH, you cannot just use sleep, since very often, those systems do
>> not have anything like carrier or collision detection.
>
>Except that I am the only master on this line... so perhaps can I do a
>sleep() though
If you sleep too long, the slave will start to transmit before
you shut off RTS, and you'll miss the start of the slave's reply.
--
Grant Edwards grante Yow! I'm GLAD I
at remembered to XEROX all
visi.com my UNDERSHIRTS!!
------------------------------
From: "Ross Smith" <[EMAIL PROTECTED]>
Subject: Re: linux kernel not C++ friendly?
Date: Fri, 19 May 2000 15:27:21 +1200
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> What library features am I missing? Are you saying I need things like
> <iostream> or the STL in order to use C++? That's not true any more than
> that I need strftime(), qsort(), frexp() or wcstombs() in order to do kernel
> programming in C.
Come to think of it, you probably *could* use most of the STL in
kernel code. It's essentially all in headers, with no runtime support
needed.
--
Ross Smith <[EMAIL PROTECTED]> The Internet Group, Auckland, New Zealand
========================================================================
"So that's 2 T-1s and a newsfeed ... would you like clues with that?"
-- Peter Da Silva
------------------------------
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: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Fri, 19 May 2000 03:41:59 GMT
[EMAIL PROTECTED] (Victor Wagner) writes:
> : 1. A streamlined, easy install process;
> Disagree. System should be installed by competent techinicans in
> computer shops. Windows is not any more easy to install than say
> Mandrake 7.0, only user do it much more frequently, so get used to it.
Never installed Mandrake, so I can't speak on this. Perhaps the
problem has already been solved.
> : 2. An office suite roughly as functional as Office, and at least as
> : easy to use;
> But based on quite diferent ideas - it shouldn't be so bloated and
> should have ability to use its components in scripts, and add own
> components written as simple scripts or C programs to common GUI.
I'll go along with that. It definitely shouldn't be the *same* as
Office - you should just be able to do the same things with it as you
would with the MS correspondent.
> : 3. A GUI package installation mechanism that's as easy to use as
> : InstallShield (trivial if we get a file manager for GNOME or KDE); and
> Whats wrong with capt?
The fact that I've never heard of it? I'm guessing it's apt-based;
the only apt GUI I've used is gnome-apt. It'll be nice when someone
puts some time into it.
> : 4. A GUI interface to the most common configuration files.
> Never, never, never let user who doesn't understand things tweak the
> config files. For such users remote sysadmin service via SSH should be
> provided.
Huh?
Are you suggesting we start up a Centralized Linux Administration
Bureau or something? And remember that not all computers are on a
network, and very few of them are on one all the time.
> : 1. A GUI interface to *all* configuration files;
> I've expressed my opinion above. I'd prefer something like expert system
> - somethig which allows to ask question on natural language, and answer
> with extracts of man and howto. NO GUI - interface just like micq, but
> much more interactivity than stupid office equipment in MS Office
> 2000.
I prefer CLI for most purposes, but nobody outside of our little
hacker niche will use Linux unless there's a usable GUI.
> : 2. Integration of all Linux documentation into a centralized,
> : searchable help center;
> Whats wrong with dwww?
Again, never heard of it.
Does it have *all* Linux documentation? Man pages, info pages, PS
files, HTML files, all integrated into a single common format and UI?
> : 3. A DirectX-like platform for hardware-accelerated devices, not
> : necessarily at the kernel level;
> Whats wrong with OpenGL?
The fact that it's not hardware-accelerated? Perhaps this will go
away as of XF86 4.0, but audio can also be hardware-accelerated.
Sound support on Linux is abysmal at best.
> : 4. Abstraction of many protocols and features, ala ODBC (which I hate
> : because it never works, not because it's a bad idea); and
> Whats wrong with
> 1. ODBC?
Is there ODBC for Linux?
> 2. DBI/DBD?
Never heard of them.
> : 4. A "killer app." Unfortately, the odds of this being in the office
> : suite are about zero, as MS has far too much of an edge on this
> : front. The GIMP, with a few unique features, may have the
> : potential to get there.
> Given Adobe PhotoShop for Linux coming in half a year?
Will it be free?
> No, if apache is not killer app, you'll have to invent totally new way
> of using computers.
Apache isn't a killer app. The reason is that only webmasters use web
servers. A killer app is something that most computer users will find
useful.
You might've noticed that a lot of my answers are "Never heard of it."
That's a problem too. There are just too many Linux programs, many of
which do the same or similar things.
--
Eric P. McCoy ([EMAIL PROTECTED])
non-combatant, n. A dead Quaker.
- Ambrose Bierce, _The Devil's Dictionary_
------------------------------
From: <Gonzales>
Crossposted-To: comp.os.linux.development.apps,comp.software-eng,alt.os.linux
Subject: Re: #include <linux/sched.h>
Date: Thu, 18 May 2000 23:04:13 -0500
You have to rebuild the kernel or something like that. I had the same
problem when I was trying to build a kernel module that I made. So then I
tried to rebuild the kernel. You just might have to do a
make dep
if this doesn't work try building the whole thing.
to get the file <linux/autoconf.h>
"Martin Alt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> Maybe I am only blind but I only want to
> #include <linux/sched.h>
> to use the
> request_irq(0x04, &ser_int, 0, "serial", NULL);
> command and get only these error messages:
>
> bash-2.03# gcc -O -o ser sertest.c
> In file included from /usr/include/linux/fs.h:9,
> from /usr/include/linux/capability.h:13,
> from /usr/include/linux/binfmts.h:5,
> from /usr/include/linux/sched.h:8,
> from sertest.c:10:
> /usr/include/linux/config.h:4: linux/autoconf.h: No such file or
> directory
>
> Does anybody knows this problem or thas an idee?
> Regards
> Martin
>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Linux Mutexes and Conditions & 2.3.99
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 May 2000 04:26:35 GMT
On Thu, 18 May 2000 00:42:19 GMT, Bill Waddington
<[EMAIL PROTECTED]> wrote:
>
> /* in the waiting code */
>
> mutex_lock(&unit_p->mutex);
> start DMA and enable int;
> cond_timed_wait_rel(&unit_p->cond, &unit_p->mutex,
> unit_p->dma_time);
> mutex_unlock(&unit_p->mutex);
>
>
> /* in the interrupt code */
>
> mutex_lock(&unit_p->mutex);
> if(our interrupt)
> flag = 1;
> quiet the hardware;
> mutex_unlock(&unit_p->mutex);
> if(flag)
> cond_broadcast(&unit_p->cond);
Note that although the cond_timed_wait_rel indicates that it woke up for one of
three reasons---an unblocked signal is raised, the time has passed, or the
condition is signaled---a wakeup due to a timeout or raised signal doesn't mean
that the condition was not also signaled.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
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: Need ideas for university funded project for linux
Date: 19 May 2000 01:07:29 -0500
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> Never, never, never let user who doesn't understand things tweak the
>> config files. For such users remote sysadmin service via SSH should be
>> provided.
>
>Huh?
>
>Are you suggesting we start up a Centralized Linux Administration
>Bureau or something? And remember that not all computers are on a
>network, and very few of them are on one all the time.
I've suggested something similar on the freebsd newsgroup before
because they need it even worse, but they seem to think everyone
should learn to be an expert.
I think what we really need is some number of well-maintained
'master' system images (somewhere between 10 and 100 would
suffice, but the number doesn't matter) and some tools
to sync up your system to the master without breaking things
due to hardware differences. Good system administrators
would each maintain their own 'ideal' system as the master
copy, tuned for whatever purpose they want. They would
document the philosophy of the configuration (i.e. the
purpose, not the details) and keep everything up to date,
adding new things as they become available. This is work
every system administrator does anyway - we just need the
tools to share it easily. Then, instead of everyone having
to configure and tune their own system, they would just pick
a setup already built that matches their needs and periodically
sync up any updates. There would still be a small amount of
local setup to do, but the bulk of the work could be done.
Freebsd needs this more than Linux, because this is really
the function of the different distributions of Linux. I'd
just like it to be even more complete and have more choices.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
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: Need ideas for university funded project for linux
From: David Steuber <[EMAIL PROTECTED]>
Date: Fri, 19 May 2000 07:00:00 GMT
[EMAIL PROTECTED] (Miquel van Smoorenburg) writes:
' What most people don't like about KDE is that if you port your
' commercial program to Linux, you'll have to pay for a Qt license.
If you are doing that, you don't need to use Qt. If you used it for
your Windows app, then you already paid for the license, so what is the
big deal?
That said, I wouldn't mind if someone came out with a decent, high
quality C++ GUI toolkit for Linux/BSD/Un*x that was free and portable
to Windows. My only real problem with Qt is the MOC compiler. It is
a macro hack that is no different from what Microsoft uses with MFC.
In principle.
I don't consider GTK-- to be a class library. It is just a wrapper
for GTK. Not the same thing really now, is it? Not that GTK is a bad
thing. After all, there is a port of GIMP for Windows.
Anyway, use what you want for your projects. I couldn't care less
about Windows anymore, so I have no problem using Qt Free Edition. At
least not apart from MOC.
--
David Steuber | Hi! My name is David Steuber, and I am
NRA Member | a hoploholic.
All bits are significant. Some bits are more significant than others.
-- Charles Babbage Orwell
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
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: Need ideas for university funded project for linux
Date: 19 May 2000 07:00:33 GMT
In comp.os.linux.development Leslie Mikesell <[EMAIL PROTECTED]> wrote:
: RH puts all config files in etc, even the ones that don't really
: belong there. For example /usr/lib/X11/lib/xinit is a symlink to
: ./../../../etc/X11/xinit.
Well, as I said, I don't now recall what I used to have to do to redhat
spec/makefiles. But it was something along the lines of config file
placements.
:>I use /usr/local for things that weren't in my original system and
:>aren't likely to be in it for the foreseeable future. Netscape would
:>be an example, though I can't think of any good ones.
: On an stock rpm-installed Redhat - and Mandrake:
: /usr/bin/netscape
: /usr/bin/netscape-communicator
: /usr/bin/netscape-navigator
:-). Well, that's wrong then. Netscape is not part of a distribution
in any sense I can think of and its the single thing that's most likely
not to have come from the original distro o my system. Surely it should
go in /opt! I.e. "large package put together by someone else". Or has
someone finally understood a sufficient fraction of the source to
actually be able to compile it meaningfully?
Peter
------------------------------
From: "Mikko Jaakkola" <[EMAIL PROTECTED]>
Subject: Re: linux kernel not C++ friendly?
Date: Fri, 19 May 2000 07:18:22 GMT
In Windows NT I used this type of trick to do the implement the new and
delete operator (you can forget the pool-type in Linux). I cannot see why it
would not work in Linux.
void* __cdecl operator new(unsigned int size, POOL_TYPE type);
void* __cdecl operator new[](unsigned int size, POOL_TYPE type);
inline void* __cdecl operator new[](unsigned int size) {return
ExAllocatePool(NonPagedPool,size);}
inline void* __cdecl operator new(unsigned int size) {return
ExAllocatePool(NonPagedPool,size);}
inline void* __cdecl operator new(unsigned int /*size not needed,this
removes warning */,void* objectAddress){return objectAddress;}
void __cdecl operator delete(void*);
Then you probably also need some type of run-time implementation for
gloabal-object if you have any (there is no run-time calling constructor for
you in the kernel-mode). Also you would not probably get any exception
handling to work either, which might make hard to use libraries such as STL.
- Mikko
Grant Edwards <[EMAIL PROTECTED]> wrote in message
news:Hk2V4.1787$[EMAIL PROTECTED]...
> On Fri, 19 May 2000 02:09:14 GMT, Kaz Kylheku <[EMAIL PROTECTED]>
wrote:
>
> >>> Thus leading me to wonder, if a kernel module could not be developed
using C++
> >>> classes and structures?
> >>Short answer: No.
> >>
> >>Medium sized answer: You could, but you'd have to provide all the
> >>run time support usually provided by C++'s support libraries, and
> >>libc. You don't want to do this.
> >
> >I see. So it follows that to use C for writing kernel code,
> >you would also need to provide all the run time support normally
> >provided by a hosted implementation of C.
>
> Some of it. printk(), kmalloc(), and so on have already been
> written, so you as a driver writer don't have to impliment libc
> replacements. If you wanted to use C++, there might be things
> that you would have to impliment.
>
> --
> Grant Edwards grante Yow! I'm wearing
PAMPERS!!
> at
> visi.com
------------------------------
From: [EMAIL PROTECTED] (Matthew Palmer)
Subject: Re: linux kernel not C++ friendly?
Reply-To: [EMAIL PROTECTED]
Date: 19 May 2000 06:38:03 +1000
Travis Hein is of the opinion:
>I am very new to this linux world, and the art of building kernel modules.
>I noticed when i ran the c++ compiler on even the most trivial of kernel
>modules, some kernel include files make use of c++ predefined operators, like
>new, class, etc.
>
>Thus leading me to wonder, if a kernel module could not be developed using C++
>classes and structures?
IIRC, the kernel would have issues with the linkage - there's a lot of stuff
your average C++ binary relies on which is not available in the kernel.
The question is, really, why develop a module in C++? You can write in an
object-oriented style in C if you really must, and I think that C is still
much more memory efficient (a *must* when you're dealing with memory which
can't be swapped out) that C++.
--
=======================================================================
#include <disclaimer.h>
Matthew Palmer
[EMAIL PROTECTED]
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: does linux support RAMDISK???
Date: Fri, 19 May 2000 09:32:21 +0200
Mario Klebsch wrote:
> In fact, one of my favourite RAM disk implementation is tmpfs from
> Solaris. tmpfs lives in virtual memory and, IMHO, the best thing about
> tmpfs is, that you do not have to specify any size for it. If you
> store files on the tmpfs volume, they are strored in virtual memory,
> if you execute large programs, VM is used for that purpose. You can
> store as much data on the tmpfs, as you have virtual memory. If you
> remove a file on the tmpfs volume, the virtual memory ocupied by that
> file is released and can be used as main memory again.
So it's not actually a RAMDISK, but it's a filesystem implemented in
virtual memory, i.e. a combination of RAM and disk (swapspace). So the
RAM can be viewed as a cache for the filesystem residing on the swap
device, replacing the (fast) access time of RAM by the mixed (on average
slower) access time of RAM + disk. The buffer cache of Linux (and other
Unices) also does this.
So the only advantage of a virtual memory based tmpfs would be the
dynamicity of the size.
-- =
Josef M=F6llers
Fujitsu Siemens Computers
SHV Server DS 1
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: does linux support RAMDISK???
Date: Fri, 19 May 2000 10:00:26 +0200
Mario Klebsch wrote:
>
>[..]
>
> In fact, one of my favourite RAM disk implementation is tmpfs from
> Solaris. tmpfs lives in virtual memory and, IMHO, the best thing about
> tmpfs is, that you do not have to specify any size for it. If you
Then is there any filesystem that is capable of adjusting its size on
demand, without reformatting, or even without unmounting, or even on the
fly? I have not seen a filesystem like this on linux. There are similar
solutions, but they need manual interaction by the admin.
AFAICS linux followed another strategy with that /tmp issue. Since any
io data is buffered anyway in RAM before writing it to disk, there is no
reason to make this explicit, by creating that special tmpfs, that will
be filled enough that it will have to be swapped out. That stuff would
just be another highly special case in the kernel. So its why the
hackers obviously didn't like it. Another issue is /tmp being wiped on
shutdown, do you like that? Not that shutdown is that often, but it's
against any intuition that untouched files disappear during a regular
shutdown or a crash.
Bernd.
------------------------------
** 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
******************************
