This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi!
On Tue, May 26, 2009 at 05:18:53PM +0200, Nordin wrote:
> I was studying the sourcecode of OpenBSC to get a good understanding of
> how things work.
good!
> But due to my lack of experience in Linux programming I have some
> difficulties to understand the source.
> I understand that the way bsc_hack works is based on event-queue
> concept, am I right?
we don't really have queues of events, so I think no.
> Anyway, in select.c I don't understand what's going on when it comes to
> registering and unregistering fd's in combination with linuxlist.c.
well, basically any part of the program can register a file descriptor object
(struct bsc_fd) with select.c. As part of the object, you specify
* which file descriptor
* whether you are interested in reading from it or writing to it
* a call-back function to be called when fd becomes readable or writable
select.c takes care of the event-loop, i.e. it will get notified by the
operating system once any of those file descriptors is readable/writable,
and then call the respective callback functions.
but that happens synchronously, i.e. a file-descriptor is available for
reading, then the select.c code calls the respective callback, which then
issues the actual read() system call. Afterwards, it processes the data
from the filedescriptor and does whatever it wants. When it returns
to the select.c code through the stack up to the callback and back into the
select.c code, we process the next file descriptor.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)