headers
pankaj chauhan | 1 Jan 2004 07:10
Picon
Favicon

Re: synchronization without hardware support


can u plz explain how these techniques work without
any lock prefix kind of thing. i know only about the
implementation of spinlocks for ix86, in which we have
to use a lock prefix before the instructions for
testing and storing operation of the spinlock.

i am still not understanding how we can prevent any
other processor from getting control of the bus before
our lock operation is complete , say we have just
tested the spinlock and found it to be unlocked , but
before we set it to be locked the control of bus goes
to another processor which also operates on the same
lock , now if we do'nt have any hardware support for
preventing the control of bus going to another
processor during an operation that has to be atomic,
how can we ensure atomicity and avoid races.

Rgds,
pankaj chauhan 

 --- Avishay Traeger <atraeger <at> cs.sunysb.edu> wrote: >
There are software implementations for locking. 
> I've made my own
> semaphore classes in the end and used them for class
> projects, and if I
> remember correctly there are a couple other ways of
> implementing
> synchronization.
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nir Tzachar | 1 Jan 2004 07:51
Picon
Picon
Favicon

Re: synchronization without hardware support

well, why wont some of the classic solutions help you here?
smth like peterson's mutual exclusion algorithm, or Dijkstra's?
they are software solutions, and do not depend on bus locking (or 
whatever). 

> those generally fall apart if the cpu also has a cpu store buffer and a
> weakly ordered memory model ;)
if you referred to one of the mentioned algorithms, can you please explain?

cheers,
--

-- 
========================================================================
nir.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/
Permalink | Reply | 4 comments |
headers
jnf | 1 Jan 2004 09:16

sock_map_fd()

Hello,

While I have been sitting here grappling trying to get a file descriptor
from a sock struct, I realized that sys_socket() calls a function called
sock_map_fd, unfortunatley it is not exported so does anyone know anything
similar, or an *easy* way to implement this? I tried replicating it, but
unfortunatly many of the functions called also are not exported.

J.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/
Permalink | Reply | 0 comments |
headers
Arjan van de Ven | 1 Jan 2004 10:50
Picon
Favicon

Re: synchronization without hardware support

On Thu, Jan 01, 2004 at 08:51:35AM +0200, Nir Tzachar wrote:
> > those generally fall apart if the cpu also has a cpu store buffer and a
> > weakly ordered memory model ;)
> if you referred to one of the mentioned algorithms, can you please explain?

a cpu with a store buffer and a weakly ordered memory model will not have
it's writes to memory visible to other cpus without explicit
synchronisation......
Permalink | Reply | 3 comments |
headers
Nir Tzachar | 1 Jan 2004 12:51
Picon
Picon
Favicon

Re: synchronization without hardware support

> On Thu, Jan 01, 2004 at 08:51:35AM +0200, Nir Tzachar wrote:
> > > those generally fall apart if the cpu also has a cpu store buffer and a
> > > weakly ordered memory model ;)
> > if you referred to one of the mentioned algorithms, can you please explain?
> 
> a cpu with a store buffer and a weakly ordered memory model will not have
> it's writes to memory visible to other cpus without explicit
> synchronisation...... 

ok, got it. but hey, if ur cpu has a store buffer or uses a weakly 
ordered memory model, then you also got some synchronization primitives, 
(ie; memory barriers, which can be used to implement a higher 
synchronization primitive) no? otherwise, the cpu manufacturer has done a 
pretty bad job....

anyway, if his cpu does not implement any synchronization primitives, then 
he got a uni-processor box (very likely.. ), and all his problems can be 
solved with one of these algorithms.

 -- 
========================================================================
nir.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/
Permalink | Reply | 2 comments |
headers
jnf | 1 Jan 2004 15:14

RE: sock_map_fd()

Just an fyi for all the people rushing to answer my question.
i solved this by upgrading to 2.6.0 where the symbol is now exported.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/
Permalink | Reply | 0 comments |
headers
Tim Cambrant | 1 Jan 2004 15:39

What was your first kernel hack?

Hi, I am new to Linux kernel development and fairly novice
to programming in general, and I'm having the usual "Don't
know where to begin"-problem. I read the code to try to
understand how things work, such as the scheduler etc, but
it's all too complex for me to even make a simple but useful
kernel module or driver yet.

Now I was thinking about what you all did to get your hands
dirty. It would be nice if you shared a bit of where you
begun with kernel-coding and what you did. It doesn't
necessarily have to be code that was accepted into the
kernel, but just regular newbie-stuff that got you started.

Happy new year everyone.

--

-- 
Tim Cambrant <tim <at> cambrant.com> 
GPG KeyID 0x59518702
Fingerprint: 14FE 03AE C2D1 072A 87D0  BC4D FA9E 02D8 5951 8702
Permalink | Reply | 3 comments |
headers
Daniel Drake | 1 Jan 2004 16:52
Favicon

Re: What was your first kernel hack?

Hi,

My experience: I had a problem with the USB printer driver (usblp) on one of 
the earlier 2.6.0-test kernels. I reported the bug, and was asked to compile 
the driver with debug info. I added the #define to include this in compilation.

After that define was added, and the debug code was to be compiled in, the 
driver did not compile - the debug code had been copy/pasted from the 2.4 
driver, but not updated to work with the 2.6 structures.  I fixed the debug 
code, and later on found some problems with the debug code in other USB 
drivers too and fixed the code there.
These were all small (1-3 line) fixes here and there.

Since then, I've stepped back to desktop-orientated hacking to brush up my C 
skills a bit. But I've also bought a couple of books on the kernel, and 
learning a lot from watching the LKML closely.

Daniel.

Since then, I've been
Tim Cambrant wrote:
> Hi, I am new to Linux kernel development and fairly novice
> to programming in general, and I'm having the usual "Don't
> know where to begin"-problem. I read the code to try to
> understand how things work, such as the scheduler etc, but
> it's all too complex for me to even make a simple but useful
> kernel module or driver yet.
> 
> Now I was thinking about what you all did to get your hands
> dirty. It would be nice if you shared a bit of where you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik van Riel | 2 Jan 2004 04:00
Favicon

Re: What was your first kernel hack?

On Thu, 1 Jan 2004, Tim Cambrant wrote:

> Now I was thinking about what you all did to get your hands
> dirty. It would be nice if you shared a bit of where you
> begun with kernel-coding and what you did. It doesn't
> necessarily have to be code that was accepted into the
> kernel, but just regular newbie-stuff that got you started.

I suspect that one of the best ways to get started is to apply
patches to your kernel. It is easy enough to get started with,
but after you've applied enough patches there are bound to come
up patch conflicts and more subtle breakage.

Fixing those is a good challenge, it will also help you get
more familiar with the code you just patched.

Another way is to dig into one particular subsystem and learn
about that.  I started that way because I didn't have access
to the internet when I started with Linux ... but I'm pretty
sure the "apply patches until it breaks" method will make you
familiar with the code quicker ;)

Rik
--

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
(Continue reading)

Permalink | Reply | 0 comments |
headers
threadhead | 2 Jan 2004 17:05
Picon

building makefiles/modules in 2.6.0

dear list,

i was compiling/booting the new 2.6.0 stable kernel release.
everything worked fine, i am able to load modules etc.

one problem remains unsolved:
i was working on a module for the 2.4.20 kernel, that i previously used.

compilation flags for that module:
"gcc -c -O2 -W -I/mnt/src/linux-2.4.20/include -fomit-frame-pointer bleh.c"
__KERNEL__ and MODULE were defined in the source file directly.

when i am compiling that module under the 2.6.0 kernel, i cannot insmod it because
it is an 'invalid module format'. i've read a dozen articles about that the modules are
named .ko since 2.6.0 or 2.5.0; but obviously, simply renaming the object file doesnt fix that.

i've also read, that it is required to link the module, against the current
source tree of the configured and compiled kernel tree.

my question is now, how am i able to build my module in a simple way so that i can insmod it?
there has to be a way to write a simple makefile that will build your module, no?

thanks for your time
threadhead

PS: yes i read
http://lwn.net/Articles/21823/
http://lwn.net/Articles/driver-porting/

i tried the makefile posted in one of the articles, but it doesnt work because:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane