|
|
|
|
|
|
| Author |
Message |
Kasper Dupont
*nix forums Guru
Joined: 20 Feb 2005
Posts: 1167
|
 Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
VSS wrote:
| Quote: |
Hi Guys,
My question was pertaining to tasks *inside* the kernel. What I really
want to do is this.
I have some callbacks which get called in the kernel. I want to send a
cook up a message and send it to the other task(B). Task B just keeps
waiting for these messages and handles the message. Is it possible to do
this?
|
Why do you want to do that? Why do you want to communicate
with a different thread, when you can just do it yourself?
--
Kasper Dupont |
|
| Back to top |
|
 |
Peter T. Breuer
*nix forums Guru
Joined: 19 Feb 2005
Posts: 1222
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
In comp.os.linux.development.system VSS <vividh@dslextreme.com> wrote:
| Quote: | My question was pertaining to tasks *inside* the kernel. What I really
|
And what do you mean by "tasks"? There are kernel threads; well, there
are threads - some of them started from within the kernel.
| Quote: | want to do is this.
I have some callbacks which get called in the kernel. I want to send a
cook up a message and send it to the other task(B). Task B just keeps
waiting for these messages and handles the message. Is it possible to do
this?
|
Yes. What's the problem? Put your message someplace and signal when it's
ready to be read. Have the other thread sleep on that signal. Or use a
semaphore.
Peter |
|
| Back to top |
|
|
Steve Ackman
*nix forums addict
Joined: 31 Mar 2005
Posts: 71
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: Linux on GlobalPC with 8M ram
|
|
|
[follow-up set to alt.os.linux]
On Sat, 19 Feb 2005 02:52:17 GMT, Rudy Hartmann wrote:
| Quote: | I have an opportunity to acquire some Internet PC's that were made by a
defunct company called GlobalPC. These machines at present are configured to
run Geos. But I would like to run an operating system that is not extinct.
|
The ownership of Desktop Geos has gone through a few changes, first to
NewDeal and then to Breadbox, but I'd have to say that with this hardware,
that will probably be your best bet. It's not extinct per se... see
http://breadbox.com
I used to run Geos on a 386-20SX w/ ONE MB RAM, so with eight times
that, you've got a system with TONS of RAM to spare.
| Quote: | I
have played with tiny versions of Linux and I have had some limited success.
These machines can run DOS too. But if I have to pay big money to update
every machine its not going to be profitable or worth the trouble. They are
based on an AMD Elan SC410-100AC processor with just under 8M of EDO DRAM.
|
This is enough to run a few apps in a console. You can even run
lightweight X apps, either standalone, or with a very lightweight window
manager.
When I was running a 2.0.x kernel, X, fvwm2, and Netscape 3.01 on a
K5-75 with 8MB RAM, everything worked fine, but was almost unbearably slow
as it hit swap all the time. To run this minimal combination, you'd want
at least 12MB RAM, and as a practical matter, 16MB is about the minimum if
you're going to try to run several lightweight X apps, or even a single
iteration of GIMP or other graphics/memory intensive programs.
You never did say exactly what it is you want to do with these machines.
| Quote: | The small footprint is one of the biggest challenges. They have an ALI M5042
and M5113 chipset. They also have one 1.4M floppy and a 4.3G hardisk. The
VGA chip is an IGS Technologies CyberPro 2010 that supports SVGA and NTSC
composite video. They have a PS/2 interface mouse and keyboard. They are
also configured with a Yamaha YMF715-ES sound chip and a Conexant R6764-63
modem. I would really like to see if I could get Linux running on this
machine. Hardware upgrade on these machines are impractical.
|
I have no doubt you can get Linux on them. The question is, "then
what?"
| Quote: | If I can get a tiny version of Linux to run on these, I would like to make
some install diskettes that reformat the hard drive and install it all on
there from this stack of diskettes. Once I get a basic Linux and X system
working, I would like to put a bunch of stuff on a website to download for
free. There are about 12K of these PC's left.
|
Then again, with that many machines, clustering might be a way to go.
--
Steve Ackman
http://twoloonscoffee.com (Need beans?)
http://twovoyagers.com (glass, linux & other stuff) |
|
| Back to top |
|
|
guruteck@gmail.com
*nix forums beginner
Joined: 19 Feb 2005
Posts: 14
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
Yeah
Only Threads lies inside Kernel.Use kmalloc and allocate buffer ,store
messages in that buffer.Use an Interrupt mechanism to send the message
to another process when it is ready.In Interrupt handler read from the
allocated buffer.
For advanced operation u can use some buffer management ..
I think this solves ur problem....
Regards |
|
| Back to top |
|
|
Mark H Johnson
*nix forums beginner
Joined: 19 Feb 2005
Posts: 4
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
VSS wrote:
| Quote: | Inside the Linux kernel how is the mechanism to do the following.
TaskA <--> msgQ <--> TaskB
Is there a way I can do this?
|
I can think of several different methods such as:
- sockets
- a pair of pipes (named or otherwise)
- pseudo terminals (pty's)
- shared memory w/ semaphores
- MPI / PVM / CORBA or another message passing system (usually built
on top of one of the mechanisms already listed)
and so on. Just analyze their capabilities and pick one.
--Mark |
|
| Back to top |
|
|
J Jackson
*nix forums beginner
Joined: 24 Feb 2005
Posts: 19
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: Linux on a small PC system
|
|
|
linnix <me@linnix.info-for.us> wrote:
: >
: > I would like to write test results to external USB flash memory
: stick,
: > so user can take it out and put it to "big" PC for analysis.
: You should mount the system drive read-only; otherwise, updating the
: flash every few seconds will shorten it's life. You can buffer and
: write to external flash memory as needed.
You can make and use compact flash drives r/w - just make sure you use the
the "noatime" option. Just be careful that your setup does as few writes
to the root partition as possible - Skip running syslog, or put /var/log
in a ram disk, etc etc.
: For more details on flash memory wearings, see
: http://cfd.linnix.com/main.php?mtbf
Another way of looking at this is write limit 100,000 you rewrite the
whole "disk" 10 times a day -> 10,000 days lifetime or 27 years. Given
each write will only cause one flash block to be written and there is some
level-wearing in the internal controller - you probably have some extra
headroom there - just be carefull with writes.
Jim |
|
| Back to top |
|
|
Mark H Johnson
*nix forums beginner
Joined: 19 Feb 2005
Posts: 4
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
Jens.Toerring@physik.fu-berlin.de wrote:
| Quote: | In comp.os.linux.development.system Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
VSS wrote:
Inside the Linux kernel how is the mechanism to do the following.
TaskA <--> msgQ <--> TaskB
Is there a way I can do this?
I can think of several different methods such as:
- sockets
- a pair of pipes (named or otherwise)
- pseudo terminals (pty's)
- shared memory w/ semaphores
- MPI / PVM / CORBA or another message passing system (usually built
on top of one of the mechanisms already listed)
The OP was asking about the kernel, not some userland IPC methods...
Are you sure? He is asking for IPC between tasks, generally a user land |
construct. Note also that much of what I described in my answer IS
implemented in the Linux kernel - see
man 2 socket
for an example. I suggested user land examples as the last item since
they may be easier to use / or more portable than the direct system call
interfaces.
| Quote: | And there's no need for IPC inside the kernel since everything in
the kernel has access to all kernel memory.
Eh? I do not see this comment being helpful at all to the OP nor |
relevant to my comment. Please explain your rationale.
--Mark |
|
| Back to top |
|
|
VSS
*nix forums beginner
Joined: 19 Feb 2005
Posts: 1
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
Hi Guys,
My question was pertaining to tasks *inside* the kernel. What I really
want to do is this.
I have some callbacks which get called in the kernel. I want to send a
cook up a message and send it to the other task(B). Task B just keeps
waiting for these messages and handles the message. Is it possible to do
this?
Thanks,
Vividh
Jens.Toerring@physik.fu-berlin.de wrote:
| Quote: | In comp.os.linux.development.system Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
Jens.Toerring@physik.fu-berlin.de wrote:
In comp.os.linux.development.system Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
VSS wrote:
Inside the Linux kernel how is the mechanism to do the following.
TaskA <--> msgQ <--> TaskB
Is there a way I can do this?
I can think of several different methods such as:
- sockets
- a pair of pipes (named or otherwise)
- pseudo terminals (pty's)
- shared memory w/ semaphores
- MPI / PVM / CORBA or another message passing system (usually built
on top of one of the mechanisms already listed)
The OP was asking about the kernel, not some userland IPC methods...
Are you sure?
I think so because of the subject line "IPC between tasks in kernel"
and the "Inside the Linux kernel" part in the question - but I can,
of course, be wrong;-) The other possibility I would see is that the
OP wants to know how support for things like shared memory/message
queues etc. is implemented within the kernel. It would be definitely
good if he/she would explain more clearly what's that all about...
He is asking for IPC between tasks, generally a user land
construct. Note also that much of what I described in my answer IS
implemented in the Linux kernel - see
man 2 socket
for an example. I suggested user land examples as the last item since
they may be easier to use / or more portable than the direct system call
interfaces.
And there's no need for IPC inside the kernel since everything in
the kernel has access to all kernel memory.
Eh? I do not see this comment being helpful at all to the OP nor
relevant to my comment. Please explain your rationale.
I just meant that (according to my interpretation of the question) that
there'ss no need for some "IPC" within the kernel since within the kernel
different "tasks" don't have separate address spaces. So "TaskA" could
set up e.g. some (non-static) structure and that way "TaskB" could read
what "TaskA" put in there and write into it whatever it thinks necessary.
Regards, Jens |
|
|
| Back to top |
|
|
Jens.Toerring@physik.fu-b
*nix forums Guru Wannabe
Joined: 19 Feb 2005
Posts: 107
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
In comp.os.linux.development.system Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
| Quote: | VSS wrote:
Inside the Linux kernel how is the mechanism to do the following.
TaskA <--> msgQ <--> TaskB
Is there a way I can do this?
I can think of several different methods such as:
- sockets
- a pair of pipes (named or otherwise)
- pseudo terminals (pty's)
- shared memory w/ semaphores
- MPI / PVM / CORBA or another message passing system (usually built
on top of one of the mechanisms already listed)
|
The OP was asking about the kernel, not some userland IPC methods...
And there's no need for IPC inside the kernel since everything in
the kernel has access to all kernel memory.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de |
|
| Back to top |
|
|
Anthony Marchini
*nix forums beginner
Joined: 19 Feb 2005
Posts: 1
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: "keyboard wedge" software??
|
|
|
R P MacKay wrote:
| Quote: | "Keyboard wedge" software monitors a serial port, and stuffs any
incoming characters into the keyboard buffer.
Stuff like that is easy under windows, because windows is basically a |
one seat kind of operating system. One person sits down and keystrokes
get sent as messages to an awaiting text entry area.
Linux is built as a multiuser operaing system from the start, so where
the keystroke would be sent would be quite a problem if two people are
logged in at one time, not generally a problem in the embedded realm
where an operating system will pretty much run one application.
To do what you want , I guess you would have to patch the kernel to such
an extent as to have it open the serial port for input and transfer data
passed in from it through to the "current console" the same way
keystrokes from the keyboard would be routed.
I don't know, but perhaps it is possible to open a connection to a
"console tty" and write data to it.
Linux somehow is able to route standard in and standard out to a serial
console , when a true graphical screen isn't being used, so it stands to
reason that someone could patch it in such a way to take standard input
from a keyboard and a serial port simultaneously.
In the time it would take to look it up and program it you could just
write a thread that opens the serial port and grabs the characters
yourself and stuffs them were you will them.
As far as capturing USB data, it depends on how they map the USB
inteface. They may simply map it into the serial port space, in which
case, if a linux driver exists for that USB serial port interface , then
you could open that virtual serial port and capture the characters as well.
I realize that doing it yourself is what you are trying to avoid here,
but that may be your only option.
My two cents.
Tony |
|
| Back to top |
|
|
Jens.Toerring@physik.fu-b
*nix forums Guru Wannabe
Joined: 19 Feb 2005
Posts: 107
|
| Posted: Sat Feb 19, 2005 10:29 pm Post subject:
Re: IPC between tasks in kernel
|
|
|
In comp.os.linux.development.system Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
| Quote: | Jens.Toerring@physik.fu-berlin.de wrote:
In comp.os.linux.development.system Mark H Johnson <mark_h_johnson@raytheon.com> wrote:
VSS wrote:
Inside the Linux kernel how is the mechanism to do the following.
TaskA <--> msgQ <--> TaskB
Is there a way I can do this?
I can think of several different methods such as:
- sockets
- a pair of pipes (named or otherwise)
- pseudo terminals (pty's)
- shared memory w/ semaphores
- MPI / PVM / CORBA or another message passing system (usually built
on top of one of the mechanisms already listed)
The OP was asking about the kernel, not some userland IPC methods...
Are you sure?
|
I think so because of the subject line "IPC between tasks in kernel"
and the "Inside the Linux kernel" part in the question - but I can,
of course, be wrong;-) The other possibility I would see is that the
OP wants to know how support for things like shared memory/message
queues etc. is implemented within the kernel. It would be definitely
good if he/she would explain more clearly what's that all about...
He is asking for IPC between tasks, generally a user land
| Quote: | construct. Note also that much of what I described in my answer IS
implemented in the Linux kernel - see
man 2 socket
for an example. I suggested user land examples as the last item since
they may be easier to use / or more portable than the direct system call
interfaces.
And there's no need for IPC inside the kernel since everything in
the kernel has access to all kernel memory.
Eh? I do not see this comment being helpful at all to the OP nor
relevant to my comment. Please explain your rationale.
|
I just meant that (according to my interpretation of the question) that
there'ss no need for some "IPC" within the kernel since within the kernel
different "tasks" don't have separate address spaces. So "TaskA" could
set up e.g. some (non-static) structure and that way "TaskB" could read
what "TaskA" put in there and write into it whatever it thinks necessary.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de |
|
| Back to top |
|
|
Guest
|
| Posted: Mon Feb 21, 2005 6:00 am Post subject:
Re: Porting Bluetooth Stack in Arm-Linux into VxWorks
|
|
|
Hi ,
do you mean to say that
'porting bluez protocol stack ' into VxWorks violates GPL.
Actually i have not thought of the GPL here.
Could you please tell me in detail.
It would of great helpto me.
Tonnes of thanks in advance,
karthik bala guru. |
|
| Back to top |
|
|
Ulf Samuelsson
*nix forums beginner
Joined: 21 Feb 2005
Posts: 11
|
| Posted: Mon Feb 21, 2005 4:34 pm Post subject:
Re: Porting Bluetooth Stack in Arm-Linux into VxWorks
|
|
|
<bluekarthik@yahoo.com> skrev i meddelandet
news:1108969221.599472.295580@c13g2000cwb.googlegroups.com...
| Quote: | Hi ,
do you mean to say that
'porting bluez protocol stack ' into VxWorks violates GPL.
Actually i have not thought of the GPL here.
Could you please tell me in detail.
It would of great helpto me.
Tonnes of thanks in advance,
karthik bala guru.
It doesnt violate GPL, you just have to put the VxWorks source code into GPL |
which probably violates the agreement with Wind River.
--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden. |
|
| Back to top |
|
|
BB
*nix forums beginner
Joined: 04 Apr 2005
Posts: 18
|
| Posted: Tue Feb 22, 2005 11:07 am Post subject:
Re: SIM Manager in Qtopia Phone Edition
|
|
|
| Quote: | There is a tool called GSM tool in OPIE the free version of QT.
From GSM tool u cld write SMS....hope this helps u.
|
Thanks a for the input. But my requirement is not to send an SMS, but
it is to be able to write an SMS content to the SMS file residing on
the SIM, and even be able to read it back.
Can I do this using the Qtopia Phone Edition?
Or else is there any other Linux open source which helps to do this? |
|
| Back to top |
|
|
Robert Kaiser
*nix forums beginner
Joined: 22 Feb 2005
Posts: 34
|
| Posted: Tue Feb 22, 2005 1:05 pm Post subject:
Re: shared libs
|
|
|
In article <cv1gf1$ggc$02$4@news.t-online.com>,
Rainer Lehrig <lehrig@t-online.de> writes:
| Quote: | .so files are shared object libraries (dynamic linking)
.a files are static librarries
The advantage of .so files is, that they can be used by many applications.
The advantage of .a files is, that everything is linked into your
application. Thus you have no external dependencies.
|
True.
A potential disadvantage of .so files that is sometimes relevant
for low resource (e.g. embedded) systems is that they need to provide
all bells and whistles that any conceivable user of the library might
ever require. So, for example, glibc, which just about any program
needs, has grown quite big and only a very small fraction of user
programs (if any) actually uses all the functionality contained.
If you look at the the *combined* footprints of glibc and a
hello-world-style application, you may end up using considerably
less resources with a statically linked program. Of course, this
advantage vanishes as soon as you need more than -say- 20 user
programs, but for e.g. busybox-based embedded systems, static
linking can result in significantly lower resource requirements.
Rob
--
Robert Kaiser email: rkaiser AT sysgo DOT com
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.com |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Wed Dec 03, 2008 11:56 pm | All times are GMT
|
|
Online Advertising | Loans | Personal Loans | Mortgage Calculator | Shares
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
embedded
