I dont know anything about the kevent timer stuff, so you should
probably look into that before re-inventing the wheel. However, you
would only need 1 thread to implement this timer functionality.
There are a couple data structures you could use, but it would probably
be easiest to use a prior
On Thu, Jul 22, 2004 at 09:56:00PM -0500, Dan Nelson wrote:
> You could also use the kqueue/kevent functions to queue up an arbitrary
> number of timer events in a single process.
I wrote a small routing daemon which uses kqueue/kevent to fire a period
timer on a quantum which in turn calls into a
Hi, re rule-based configuration Chris Pressey noted:
> That's the easy part. The hard part is discovering the dependencies.
My impression is that almost all rule-based expert
systems of sufficient complexity that deal with a
dynamic field have failed because of this, that is,
due to the dif
In the last episode (Jul 22), pradeep reddy punnam said:
> i thought of threading with select before , but i belive that if
> the number of timers to be checked increases the number of the
> threads to be maintained increses,so the process may become very
> hevy. what do u think.
Threads are very
HI joseph ,
i thought of threading with select before , but i belive that if the
number of timers to be checked increases the number of the threads to be maintained
increses,so the process may become very hevy. what do u think.
i think ultimatley i am going to use the above t
On Tue, 20 Jul 2004 19:39:31 -0500 (CDT)
"Conrad J. Sabatier" <[EMAIL PROTECTED]> wrote:
> Just musing on an idea here:
>
> I've been thinking for a while now about trying to write a tool to
> make kernel configuration easier, sort of a "make config" (as in
> ports) for the kernel, similar to wha
If you're willing to take some precautions, you could run the timer code
with select/usleep in a separate thread. However, since the callbacks
would originate from that thread, you would need mutexes to protect any
data that the function accesses that could also be accessed by the
normal progr
HI all,
i am working on a project , where i came across a situation where i need
to execute a function when a timer expires ,exactly similar to functionality of the
timeout() kernel function but i need this in userland(application), and the execution
of the function is time sensit
> The debate here is automation vs. simplification. Why we shouldn't
> simplificate the kernel compile ? Because our user base's average IQ will
> be lower ? We're not suggesting to have KDE installed by default here.
> Users would still to have to type the commands to compile the kernel by
> hand
Mmmm... I had something similar (much smaller) supplied with
my Cromemco Z-80 CROMIX system... early 80's for the historical.
You were prompted through a series of questions re the desired
requirements for i/o devices etc. and then the last step would rebuild
the 'kernel' to that configuration.
I
> You confuse automation, with simplification.
> Automation tools are good for frequently re-run tasks.
> How often do you recompile your kernel?
>
> exactly.
In my opinion, the least we could do is have it as a port/package. For the
make check dependencies, that could be a great idea to comm
Hi Charles,
I sent this message. But SpamCop.net had listed
my ISP address. I received undelivered message.
So I will send again.
Eitarou
Eitarou Kamo wrote:
Hi,
How about this?
1. You mount dd.img as vn0 like this in your free space.
#vnconfig vn0 dd.img
# mount /dev/vn0c /mnt
2. archive or dump w
On Wed, 2004-07-21 at 11:12, Dan Nelson wrote:
> In the last episode (Jul 20), Joe Marcus Clarke said:
> > What is the canonical way for a userland application to get the
> > fully-qualified path of an executable from its running PID? I know I
> > can do a readlink(2) on /proc/pid/file, but procfs
On 21-Jul-2004 Devon H. O'Dell wrote:
> I'm sure this will become another bikeshed, so I suggest whoever came
> up with the idea to put up or shut up. People are interested in
> solutions, not suggestions.
Agreed. And the original proponent of the idea was me. I just wanted
to see if there was
On 21-Jul-2004 M. Warner Losh wrote:
> In message:
> <[EMAIL PROTECTED]>
> Murray Taylor <[EMAIL PROTECTED]> writes:
>: As an initial starting point for 'preloading' any menubased kernel
>: configurator, could the file /var/run/dmesg.boot be usefully parsed
>: as
>: a list of 'this is
On Tue, 2004-Jul-20 14:01:06 -0400, Charles Sprickman wrote:
>On Tue, 20 Jul 2004, Peter Jeremy wrote:
>
>> It's difficult to see how a sanely written RAID utility could totally
>> screw up an array in a short time
Upon reflection, one obvious way is to change the array layout. I
don't know enoug
On Wed, Jul 21, 2004 at 02:52:07PM +0200, Devon H. O'Dell wrote:
> I wholly disagree. I think using an excuse ``people will let everything
> else do the work for them and nobody will ever learn'' to discourage the
> development of automation tools is very poor. Try applying that argument
> to an
17 matches
Mail list logo
