> -Original Message-
> From: Mike Smith [mailto:m...@smith.net.au]
> Sent: Thursday, January 21, 1999 8:25 PM
> To: p...@originative.co.uk
> Cc: curr...@freebsd.org
> Subject: Re: KLD naming
>
...
> Ah, understood. I'd be inclined to use a suffix
> I've taken this off list. I'm not sure we're quite addressing the same
> issue.
No, I think we were at angles for a bit here. But I do believe that
this is something work copying to people on the list, as you do raise a
very good point. I hope this was on -current. 8)
> > I've thought about
>
> Is there meta information in a .ko file? That way you could do a kldinfo to
> find out where to go for more info, etc.
There's not time to standardise this, so I would say that 3.x .ko files
won't have metainformation internally, no. Certainly 4.x .ko files
will carry a lot more metainfo
Is there meta information in a .ko file? That way you could do a kldinfo to
find out where to go for more info, etc.
On Thu, Jan 21, 1999 at 11:13:49AM -0800, Mike Smith wrote:
> I've thought about this, and I think it would be a very bad idea.
>
> We want to keep this *simple*. In the case o
> > Well whistle is giving htis away so we don'tthink it should
> > be whistle_xxx
> > any more than the kernel should be UCB/...
> > It occur to me that eventually every single device driver
> > will be a KLD
> > an also a lot of other things besides...
> > there are going to be a LOT of files
> -Original Message-
> From: Julian Elischer [mailto:jul...@whistle.com]
> Sent: Thursday, January 21, 1999 5:39 PM
> To: p...@originative.co.uk
> Cc: m...@smith.net.au; c...@adsu.bellsouth.com; obr...@nuxi.com;
> curr...@freebsd.org
> Subject: RE: KLD naming
>
On Thu, 21 Jan 1999, Christian Kuhtz wrote:
> On Thu, Jan 21, 1999 at 09:34:28AM +, Doug Rabson wrote:
> > On Wed, 20 Jan 1999, Mike Smith wrote:
> >
> > > I guess it depends on how fancy we want to get. Here are some examples
> > > that I've been rolling around; some are fanciful, some p
On Thu, 21 Jan 1999 p...@originative.co.uk wrote:
>
> Why not have a third party identifier on the front, e.g.
>
> whistle_ng_rfc1490
>
> You can determine your own naming scheme then and if we make this
> standard then it will ensure that third party supplied modules don't
> result in name sp
On Thu, Jan 21, 1999 at 09:34:28AM +, Doug Rabson wrote:
> On Wed, 20 Jan 1999, Mike Smith wrote:
>
> > I guess it depends on how fancy we want to get. Here are some examples
> > that I've been rolling around; some are fanciful, some practical)
> >
> > dev_generic device (eg
> -Original Message-
> From: Julian Elischer [mailto:jul...@whistle.com]
> Sent: Thursday, January 21, 1999 7:58 AM
> To: Mike Smith
> Cc: Christian Kuhtz; David O'Brien; curr...@freebsd.org
> Subject: Re: KLD naming
>
>
> well you're about to get y
On Wed, 20 Jan 1999, Mike Smith wrote:
> I guess it depends on how fancy we want to get. Here are some examples
> that I've been rolling around; some are fanciful, some practical)
>
> dev_generic device (eg. dev_sio)
> bus_bus support (eg. bus_pci)
> ne
> well you're about to get your first test
> we are releasing the netgrpah code in full production form tonigh (if
> the version we've put together for release passes all tests tonight)
> The whole thing installs as KLD modules (or linked in of course)
>
> our present names are all predicated
well you're about to get your first test
we are releasing the netgrpah code in full production form tonigh (if
the version we've put together for release passes all tests tonight)
The whole thing installs as KLD modules (or linked in of course)
our present names are all predicated with ng_
h
> I guess it depends on how fancy we want to get. Here are some examples
> that I've been rolling around; some are fanciful, some practical)
>
> dev_generic device (eg. dev_sio)
> bus_bus support (eg. bus_pci)
> netif_ network interface (eg. net
> On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote:
> [..]
> > etc? This is what the original poster suggested, and nobody has really
> > given a good response what is wrong with the "grouping" being expressed
> > in the modules' name. Mike Smith and Andrzej Bialecki have given good
On Wed, 20 Jan 1999, Mike Smith wrote:
> > I was just pointing out that having things in subdirectories
> > is better than having a zillion files piled into a single directory.
>
> I'm torn between agreeing that it's tidier and disagreeing on the
> grounds that it's much more of a pain to admini
On Wed, Jan 20, 1999 at 07:19:15PM -0800, David O'Brien wrote:
[..]
> etc? This is what the original poster suggested, and nobody has really
> given a good response what is wrong with the "grouping" being expressed
> in the modules' name. Mike Smith and Andrzej Bialecki have given good
> reasons
Why not just follow the directory structure under /sys?
Afterall, we are talking about kernel stuff here.
On Wed, Jan 20, 1999 at 10:58:13AM -, p...@originative.co.uk wrote:
[..]
> I don't think subdirectories based on bus type is a good idea, it
> doesn't really fit the granularity we're p
> Perhaps something more along the lines of:
>
> /modules<- empty, except for directories
> /console<- console related modules
> blank_saver.ko, daemon_saver.ko, fade_saver.ko, green_saver.ko,
Gross. What is wrong with:
saver_*.ko
device_*.ko
linu
On Wed, Jan 20, 1999 at 03:36:14PM -0800, Mike Smith wrote:
> [KLD module file locations]
> > I was just pointing out that having things in subdirectories
> > is better than having a zillion files piled into a single directory.
> I'm torn between agreeing that it's tidier and disagreeing on the
>
Mike Smith writes:
> > > A single directory holding module files.
> >
> > Blech :-)
>
> Put aside the aesthetics for a moment, and try to raise some real,
> practical objections. I'm continually battling my own temptation to
> make the whole module thing more complex, but if you've got really
On Wed, 20 Jan 1999, Archie Cobbs wrote:
> > > I like this idea (subdirectories) better.. it will last longer :-)
> >
> > It's a really bad idea, because it requires you to classify things. It
> > also makes it much harder to administer. In addition, classifications
> > are bad (witness the n
[KLD module file locations]
> I was just pointing out that having things in subdirectories
> is better than having a zillion files piled into a single directory.
I'm torn between agreeing that it's tidier and disagreeing on the
grounds that it's much more of a pain to administer. "Where is tha
Mike Smith writes:
> > > When I first started writing KLD, I had a vague notion that there would be
> > > a simple directory structure under /modules, e.g.:
> > >
> > > /modules
> > > pci/
> > > ncr.ko
> > > ...
> > >
> > When I first started writing KLD, I had a vague notion that there would be
> > a simple directory structure under /modules, e.g.:
> >
> > /modules
> > pci/
> > ncr.ko
> > ...
> > isa/
> >
From: Archie Cobbs
>Doug Rabson writes:
>> > Might it be a good idea to choose a consistent naming scheme for the
>> > modules? I'd think so because it would help blind loading at the boot
>> > prompt. If you choose names it the following format:
>> >
>> > type_name
>> > saver_warp
>> > saver_dae
> -Original Message-
> From: Archie Cobbs [mailto:arc...@whistle.com]
> Sent: Wednesday, January 20, 1999 6:13 AM
> To: d...@nlsystems.com
> Cc: gelde...@mediaport.org; curr...@freebsd.org
> Subject: Re: KLD naming
>
>
> Doug Rabson writes:
> > >
Doug Rabson writes:
> > Might it be a good idea to choose a consistent naming scheme for the
> > modules? I'd think so because it would help blind loading at the boot
> > prompt. If you choose names it the following format:
> >
> > type_name
> > saver_warp
> > saver_daemon
> >
> > the modules of
On Tue, 19 Jan 1999, Jeroen C. van Gelderen wrote:
> Hi,
>
> Might it be a good idea to choose a consistent naming scheme for the
> modules? I'd think so because it would help blind loading at the boot
> prompt. If you choose names it the following format:
>
> type_name
> saver_warp
> saver_daem
Hi,
Might it be a good idea to choose a consistent naming scheme for the
modules? I'd think so because it would help blind loading at the boot
prompt. If you choose names it the following format:
type_name
saver_warp
saver_daemon
the modules of one type will sort together in a directory listing.
30 matches
Mail list logo
