freebsd-hackers Digest, Vol 70, Issue 5
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: disk recovery help (Eitarou Kamo)
2. Re: "Next Generation" kernel configuration? (NicolasB?rard Nault)
3. Re: "Next Generation" kernel configuration? (Murray Taylor)
4. Re: "Next Generation" kernel configuration? (sor...@cydem.org)
5. regarding timeout/untimeout kernel functions
(pradeep reddy punnam)
6. Re: "Next Generation" kernel configuration? (Chris Pressey)
7. Re: regarding timeout/untimeout kernel functions
(pradeep reddy punnam)
8. Re: "Next Generation" kernel configuration? (Bruce R. Montague)
9. Re: regarding timeout/untimeout kernel functions
(Bruce M Simpson)
10. Re: regarding timeout/untimeout kernel functions (Joseph M Link)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Jul 2004 21:17:32 +0900
From: Eitarou Kamo <e-k...@trio.plala.or.jp>
Subject: Re: disk recovery help
To: freebsd...@freebsd.org, sp...@fasttrackmonkey.com
Message-ID: <40FFB05C...@trio.plala.or.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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 whole data of the /mnt.
>
> 3. restore archived data to /dev/ad3s1h after create file system.
>
> FSCK failed because you set the bs=1024 in the dd command,
> I guess.
>
> Charles Sprickman wrote:
>
>> On Tue, 20 Jul 2004, Eitarou Kamo wrote:
>>
>>
>>
>>
>>
>>
>
--
***********************
Eitarou Kamo
Tel. +81 75 7035997
Fax +81 75 7035997
VoIP 050 10585997(domestic only)
e-mail e-k...@trio.plala.or.jp
For business:
Feel free to mail me(above), please.
Donation http://www.PayPal.Com
GPG FingerPrint:
032D FDF9 D27B 23F7 9A81 BF4C 626C FBAA BC3A 9895
************************************************************************
------------------------------
Message: 2
Date: Thu, 22 Jul 2004 15:25:02 -0000 (GMT)
From: NicolasB?rard Nault<nic...@quebecbsd.org>
Subject: Re: "Next Generation" kernel configuration?
To: "Avleen Vig" <lists-...@silverwraith.com>
Cc: freebsd...@freebsd.org
Message-ID:
<3523.69.70.227.33....@webmail.north-zone.net>
Content-Type: text/plain;charset=iso-8859-1
> 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 commit because
right now, unless your kernel doesn't compile our your computer doesn't
start, there's no way to know you forgot something.
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 and do a little research about the options they enabled. XFree86 has
ncurses/graphic configuration utilities. Why the kernel shouldn't ?
--
Nicolas Bérard Nault (nic...@quebecbsd.org)
http://staff.xeatech.net/nicobn
PGP public key: 0x64159509
------------------------------
Message: 3
Date: Fri, 23 Jul 2004 10:33:44 +1000
From: Murray Taylor <murray...@bytecraftsystems.com>
Subject: Re: "Next Generation" kernel configuration?
To: "Bruce R. Montague" <bru...@mail.cruzio.com>
Cc: freebsd...@freebsd.org
Message-ID:
<1090542824.2...@wstaylorm.dand06.au.bytecraft.au.com>
Content-Type: text/plain
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.
It wasn't actually doing a full build as all the supplied stuff came out
of linkable libraries, BUT one could use an assembler 'template' to
create ones own device drivers for the homebrewed 'MummbleFrotz' device.
These 'user-created drivers' were then assembled, loaded into your own
library and became a linkable element from then onwards that you could
add during any subsequent 'kernel rebuilds'
If I remember correctly- the main elements of the template were
- an entry 'jump table' for such things as Initialise (ENTRY+0),
Open (ENTRY+2), Read (ENTRY+4) ....
- a place to define major:minor numbers and the rules / options
pertaining thereto,
- and finally how to return data and driver status.
Fun.
mjt
On Thu, 2004-07-22 at 06:41, Bruce R. Montague wrote:
>
> Hi, re, "Next Generation" kernel configuration:
>
> Years ago I had a job for a few years where I
> constantly built RSX-11 systems on PDP-11s. RSX-11
> was always built from source and had a couple of
> hundred build-time options, many hardware build
> dependencies, and supported numerous other dynamic
> build-time functions; it was said that it was possible
> that no 2 RSX systems were really the same binaries.
> It may have been more combinatorially complex than
> FreeBSD. An RSX build could easily take a day.
>
> Although at the core the build was driven by a file
> of assembly macro defines, conceptually not unlike
> FreeBSD, the build process went through continuous
> evolution over the life of RSX. A comprehensive
> "sysgen.bat" script, or somesuch, evolved. Sysgen
> (which was a common industry term at the time) was
> a very large script that was intended to be run on
> a fast hard-copy decwriter; it printed out lists of
> possibilities and then asked you a question, you
> made a selection from the options, and so on. It
> conducted a 'scripted dialog' that reflected the
> options you made along the way. You wanted this on
> hard copy so you could go back and check things,
> keep it for next time, and so on. You could go back
> in the dialog and repeat a section, save the sysgen
> state and restart later, and so on.
>
> A sysgen dialog could easily take half-a-day (sometimes
> intermediate things had to be built and such), and
> then the build itself and install could take a number
> of hours...
>
> At the end of the sysgen dialog you could "save the
> session", basically, and then the next time you did
> a session you could ask to use the saved session and
> essentially conduct a "modification dialog". Working
> with sysgen often felt like taking part in an adventure
> game with an AI opponent; you had to know how to
> outsmart the script to get it to do exactly what you
> wanted. This might be a common failing of many
> pseudo AI type programs.
>
> On the one had this all worked and worked well. On
> the other hand if you can do it by simply editing
> flat files it's much better, because you don't have
> to become an expert on the sysgen script just to do
> a build. Back on the other hand, there may be a point
> of complexity (and lack of corresponding widespread
> sophistication) where a sysgen program is necessary.
>
>
>
>
> SO:
>
> If a sysgen-like program was built for FreeBSD that
> used a conversational, graphic, menu, or whatever
> interface, instead of actually doing anything to
> real files or the real system, could it just print
> out _what to do_, that is, it would output a list
> of instructions - in such-and-such a file, edit this
> option, then add this line... Or perhaps it would
> output diffs to files... or put the output in a
> "candidate" location. But in any case the program
> would be a SYSGEN ASSISTANT, not an actual sysgen
> program. Basically a "kernel config checker", a smart
> build-lint, etc.. It could live in ports. If this
> program got to where it really worked, everyone liked
> the interface, and the system complexity was clearly
> at the point where it was needed, it could be used
> to directly generate system configurations.
>
>
> The dependency-rule evaluation and output part could
> be built independent of any user-interface, so a
> front-end back-end scheme might make sense.
>
>
>
> In any case, googling on "RSX sysgen" might produce
> some ideas of interest. BTW, I'm under the impression
> that for quite some time the largest rule-based AI
> application ("real-time expert system") in the world
> was the OPS5 system implemented at DEC to configure
> VAX hardware, see links such as:
>
> http://encyclopedia.thefreedictionary.com/OPS5%20rule%20based
>
> It looks like there's a public domain system that
> compiles rules to C code, perhaps there are some
> interesting ideas there as well for things like
> general dependency rule evaluation in the backend
> and such:
>
> http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/systems/ops5/0.html
>
>
> Sorry to go on at length.
>
>
> - bruce
>
>
>
>
>
>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
> ****************************************************************
> This Email has been scanned for Viruses by MailMarshal.
> ****************************************************************
--
Murray Taylor
Special Projects Engineer
---------------------------------
Bytecraft Systems & Entertainment
P: +61 3 8710 2555
F: +61 3 8710 2599
D: +61 3 9238 4275
M: +61 417 319 256
E: murray...@bytecraftsystems.com
or visit us on the web
http://www.bytecraftsystems.com
http://www.bytecraftentertainment.com
---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material.
E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------
****************************************************************
This Email has been scanned for Viruses by MailMarshal.
****************************************************************
------------------------------
Message: 4
Date: Thu, 22 Jul 2004 18:47:34 -0600
From: <sor...@cydem.org>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Message-ID: <200407221847...@cydem.org>
Content-Type: text/plain; charset="iso-8859-1"
> 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 and do a little research about the options they enabled. XFree86 has
> ncurses/graphic configuration utilities. Why the kernel shouldn't ?
Because configuring kernel by editing config files is, IMHO, the fastest
and most convenient method. New FreeBSD users should get used to it
from the beginning - this will save their time in future. There's nothing
hard in editing the files, especially after few kernels for different machines
have been created (they can be used as templates).
Timestamp: 0x41005EBC
[SorAlx] http://cydem.org.ua/
ridin' VN1500-B2
------------------------------
Message: 5
Date: Thu, 22 Jul 2004 17:59:40 -0700 (PDT)
From: pradeep reddy punnam <pra...@yahoo.com>
Subject: regarding timeout/untimeout kernel functions
To: freebsd...@freebsd.org
Message-ID: <2004072300594...@web53410.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
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 sensitive, it should be run immediately when timer expires.
i can't be using poll or select for timer becuse those will block the process untill the timer expires.for me the proess should not be blocked.
and i also thought of taking the service of the timeout function by writing a system call and using signaling mechanism but i think this will become expensive when the number of timers to be checked increeses.
i read the kern_timeout.c code that is very good implentation.with very less expensive.
but i think user unable to enjoy that service.
i will thankful if somebody can tell if there is any such a service or way provided by os( that i overlooked).
thanks,
-Pradeep
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!From owner-free...@FreeBSD.ORG Fri Jul 23 01:29:25 2004
Return-Path: <owner-free...@FreeBSD.ORG>
Delivered-To: freebsd...@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0772116A4E9
for <freebsd...@freebsd.org>;
Fri, 23 Jul 2004 01:29:25 +0000 (GMT)
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85])
by mx1.FreeBSD.org (Postfix) with ESMTP id C275343D1F
for <freebsd...@freebsd.org>;
Fri, 23 Jul 2004 01:29:24 +0000 (GMT)
(envelope-from fre...@joelink.net)
Received: from [192.168.0.3] (c-24-14-79-34.client.comcast.net[24.14.79.34])
by comcast.net (rwcrmhc12) with ESMTP
id <20040723012923014003m46re>; Fri, 23 Jul 2004 01:29:24 +0000
Message-ID: <410069F0...@joelink.net>
Date: Thu, 22 Jul 2004 20:29:20 -0500
From: Joseph M Link <fre...@joelink.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pradeep reddy punnam <pra...@yahoo.com>
References: <2004072300594...@web53410.mail.yahoo.com>
In-Reply-To: <2004072300594...@web53410.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: freebsd...@freebsd.org
Subject: Re: regarding timeout/untimeout kernel functions
X-BeenThere: freebsd...@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hac...@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd...@freebsd.org>
List-Help: <mailto:freebsd-hac...@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hac...@freebsd.org?subject=subscribe>
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 program flow.
Joe
pradeep reddy punnam wrote:
> 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 sensitive, it should be run immediately when timer expires.
>
> i can't be using poll or select for timer becuse those will block the process untill the timer expires.for me the proess should not be blocked.
> and i also thought of taking the service of the timeout function by writing a system call and using signaling mechanism but i think this will become expensive when the number of timers to be checked increeses.
>
> i read the kern_timeout.c code that is very good implentation.with very less expensive.
> but i think user unable to enjoy that service.
>
> i will thankful if somebody can tell if there is any such a service or way provided by os( that i overlooked).
>
> thanks,
>
> -Pradeep
>
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
------------------------------
Message: 6
Date: Thu, 22 Jul 2004 18:32:18 -0700
From: Chris Pressey <cpre...@catseye.mine.nu>
Subject: Re: "Next Generation" kernel configuration?
To: con...@cox.net
Cc: freebsd...@freebsd.org
Message-ID: <20040722183218.4...@catseye.mine.nu>
Content-Type: text/plain; charset=US-ASCII
On Tue, 20 Jul 2004 19:39:31 -0500 (CDT)
"Conrad J. Sabatier" <con...@cox.net> 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 what's available on some of the
> Linux distros.
>
> Ideally, such a tool would be capable of automatically adapting itself
> to handle and present as choices, in an orderly and logical fashion,
> whatever devices, options, etc. were currently available, as defined
> by the files in /sys/conf et al.
Hi,
I gave this a brief shot on DragonFly with not much luck, but maybe some
insight - here's my experience.
The kernel config file should probably be replaced by a Makefile.
This way, the user can say something like:
MYKERNEL: device_i_want another_device_i_want ...
...
And of course somewhere else (probably in an included Makefile) the
dependencies would be specified a la
device_i_want: another_device_you_also_need_for_it
...
So, you'd never get a "doomed" kernel config that starts compiling but
chokes halfway through the build, because any needed devices would be
brought in automatically.
That's the easy part. The hard part is discovering the dependencies.
If you want to discover them automatically by looking through the kernel
source code files - all I can say is, good luck! You'll either need a
really, really smart relation-mining program, or more disciplined source
code organization, or both.
Alternatively, you could ascertain a set of dependencies manually
(many of them are noted in GENERIC, LINT, NOTES, etc,) but then you'd
also have to maintain that set when they change in the future. I'm not
so sure that's much of a drawback (since currently src/sys/conf/files
has to undergo that sort of maintenance anyway,) but it's less big of a
win than having it all nicely, automatically generated from the inherent
structure of the kernel.
> The major hurdle to overcome, it appears to me, is that the scheme
> currently employed to describe the available devices, options, etc.
> does not lend itself very easily at all to any kind of automatic
> parsing or other manipulations. Determining dependencies between
> components programmatically, for one thing, seems well near
> impossible.
Precisely the conclusion I came to as well.
-Chris
------------------------------
Message: 7
Date: Thu, 22 Jul 2004 19:23:24 -0700 (PDT)
From: pradeep reddy punnam <pra...@yahoo.com>
Subject: Re: regarding timeout/untimeout kernel functions
To: Joseph M Link <fre...@joelink.net>
Cc: freebsd...@freebsd.org
Message-ID: <2004072302232...@web53409.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
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 thing.
but in the process of my search i came across the timeout kernel function implemenation
but i can not use that ( which i belive very efficient implementation of timers ), which user can not able to use it , so i just want to discuss it .
thanks
- pradeep
Joseph M Link <fre...@joelink.net> wrote:
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 program flow.
Joe
pradeep reddy punnam wrote:
> 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 sensitive, it should be run immediately when timer expires.
>
> i can't be using poll or select for timer becuse those will block the process untill the timer expires.for me the proess should not be blocked.
> and i also thought of taking the service of the timeout function by writing a system call and using signaling mechanism but i think this will become expensive when the number of timers to be checked increeses.
>
> i read the kern_timeout.c code that is very good implentation.with very less expensive.
> but i think user unable to enjoy that service.
>
> i will thankful if somebody can tell if there is any such a service or way provided by os( that i overlooked).
>
> thanks,
>
> -Pradeep
>
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!From owner-free...@FreeBSD.ORG Fri Jul 23 02:56:07 2004
Return-Path: <owner-free...@FreeBSD.ORG>
Delivered-To: freebsd...@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 768F016A4CE
for <freebsd...@freebsd.org>;
Fri, 23 Jul 2004 02:56:07 +0000 (GMT)
Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101])
by mx1.FreeBSD.org (Postfix) with ESMTP id 3020D43D49
for <freebsd...@freebsd.org>;
Fri, 23 Jul 2004 02:56:07 +0000 (GMT)
(envelope-from d...@dan.emsphone.com)
Received: (from dan@localhost)
by dan.emsphone.com (8.12.10/8.12.10) id i6N2u0Wq031936;
Thu, 22 Jul 2004 21:56:00 -0500 (CDT)
(envelope-from dan)
Date: Thu, 22 Jul 2004 21:56:00 -0500
From: Dan Nelson <dne...@allantgroup.com>
To: pradeep reddy punnam <pra...@yahoo.com>
Message-ID: <2004072302...@dan.emsphone.com>
References: <410069F0...@joelink.net>
<2004072302232...@web53409.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2004072302232...@web53409.mail.yahoo.com>
X-OS: FreeBSD 5.2-CURRENT
X-message-flag: Outlook Error
User-Agent: Mutt/1.5.6i
cc: freebsd...@freebsd.org
cc: Joseph M Link <fre...@joelink.net>
Subject: Re: regarding timeout/untimeout kernel functions
X-BeenThere: freebsd...@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hac...@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd...@freebsd.org>
List-Help: <mailto:freebsd-hac...@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hac...@freebsd.org?subject=subscribe>
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 lightweight. You should be able to create hundreds of
(mostly-sleeping) threads with no problem. You wouldn't even need to
use select; just sleep (or nanosleep).
> i think ultimatley i am going to use the above thing. but in the
> process of my search i came across the timeout kernel function
> implemenation but i can not use that ( which i belive very efficient
> implementation of timers ), which user can not able to use it , so i
> just want to discuss it .
You could also use the kqueue/kevent functions to queue up an arbitrary
number of timer events in a single process.
--
Dan Nelson
dne...@allantgroup.com
------------------------------
Message: 8
Date: Thu, 22 Jul 2004 20:05:20 -0700 (PDT)
From: "Bruce R. Montague" <bru...@mail.cruzio.com>
Subject: Re: "Next Generation" kernel configuration?
To: freebsd...@freebsd.org
Message-ID: <200407230305....@mail.cruzio.com>
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 difficulty of determining current
dependencies (rule discovery). Even the experts
don't actually know; each will know some but nobody
will know all, certainly not when the real dependencies
are evolving all the time. Even worse, there may
be many combinations of things that just don't work
but nobody realizes it yet, new things that break a
lot of old dependencies in an unknown way, etc. Even
the experts will hit this and ask on an email list,
"I did this and look what happened, anybody got any
ideas?" So the experts will know how to solve the
problem, but not in a way that can be automated.
Unix has been pretty good over its life at resisting
combinatorial complexity; RSX for instance had a
relatively high degree of optional API sets and
optional API features and similar things with kernel
primitives, this introduced a very fine level of
granularity that made for a bad dependency combinatorial
explosion (part of this resulted from the old OS/360
mantra of one system that would scale across a very
wide family, combined with paranoia about memory use).
Feature sets selected for server components depended
on other feature sets, kernel feature sets, API
feature sets, driver features sets, etc and vice
versa.
My impression -dont know if it's true- is that the
RSX experience made DEC say "never again". One
important reason was testing. Testing a system when
few others would actually be built exactly like it
raises issues... its good to know that it at least
works... but how "fragile" is it wrt other build
combinations?
The "large e-mail list" as build expert-system of
choice combined with a simple mechanism (flat files)
to act as control knobs is likely a big advantage
open source systems have over most proprietary
systems. It would be interesting to know how many
people world-wide are reasonably competent to build
FreeBSD from source compared to how many actually
know the same for NT. Maybe all the more reason to
package something as an "Assistant" type educational,
verification, or visualization tool for stable,
well-known core dependencies. FreeBSD will be around
for a long time and such a tool, if nothing else,
might help get people on board w/o any impact wrt
the current state of affairs. If nothing else, it's
an interesting problem and systems complexity is
not likely to go down anytime soon!
- bruce
------------------------------
Message: 9
Date: Fri, 23 Jul 2004 04:20:52 +0100
From: Bruce M Simpson <b...@spc.org>
Subject: Re: regarding timeout/untimeout kernel functions
To: Dan Nelson <dne...@allantgroup.com>
Cc: freebsd...@freebsd.org
Message-ID: <20040723032...@empiric.dek.spc.org>
Content-Type: text/plain; charset=us-ascii
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 timer list module I wrote,
which can either use the kevent quantum, or multiplex on a single itimer.
It's pretty basic and probably not foolproof, but it seems to work well.
BMS
------------------------------
Message: 10
Date: Thu, 22 Jul 2004 22:58:51 -0500
From: Joseph M Link <fre...@joelink.net>
Subject: Re: regarding timeout/untimeout kernel functions
To: pradeep reddy punnam <pra...@yahoo.com>
Cc: freebsd...@freebsd.org
Message-ID: <41008CF...@joelink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
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 priorityq. You insert each timer event into the
priorityq keyed on when it is due to fire. You look at first item in
the queue and subtract the current time from it (gettimeofday()) to
determine how long to sleep until the next one is ready. If use select,
you'll need to create a pipe and select on it to wake up the thread when
you insert new timer events.
Joe
pradeep reddy punnam wrote:
> 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 thing.
> but in the process of my search i came across the timeout kernel function implemenation
> but i can not use that ( which i belive very efficient implementation of timers ), which user can not able to use it , so i just want to discuss it .
>
> thanks
>
> - pradeep
>
> Joseph M Link <fre...@joelink.net> wrote:
>
> 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 program flow.
>
> Joe
>
> pradeep reddy punnam wrote:
>
>
>>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 sensitive, it should be run immediately when timer expires.
>>
>>i can't be using poll or select for timer becuse those will block the process untill the timer expires.for me the proess should not be blocked.
>>and i also thought of taking the service of the timeout function by writing a system call and using signaling mechanism but i think this will become expensive when the number of timers to be checked increeses.
>>
>>i read the kern_timeout.c code that is very good implentation.with very less expensive.
>>but i think user unable to enjoy that service.
>>
>>i will thankful if somebody can tell if there is any such a service or way provided by os( that i overlooked).
>>
>>thanks,
>>
>>-Pradeep
>>
>>
>>
>>
>>
>>
>>---------------------------------
>>Do you Yahoo!?
>>Vote for the stars of Yahoo!'s next ad campaign!
>>_______________________________________________
>>freebsd...@freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
------------------------------
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
End of freebsd-hackers Digest, Vol 70, Issue 5
**********************************************