Matthew Dillon wrote:
>
> :Well, it's also a module, so perhaps we should create the whole subtree
> :for modules (as was already discussed several times..)
> :
> :Andrzej Bialecki
>
> Yes, this is very true. But I think we are fooling ourselves if we
> believe linux emulation will not
On Mon, Aug 16, 1999 at 02:54:53PM -0700, Steve Kargl wrote:
> kern.modules seems to be slightly more general in that you can
> have kern.modules.xxx where xxx is anything under /modules that
> needs/wants to some tuning via sysctl.
This is daft. Given that we are planning on makeing everything
> I kinda like the idea of a top-level compat category; it will keep the
> top level uncluttered when sysv and iBCS compatibility start requiring
> their own knobs, and if you put linux at the top level this will later
> be used as justification for putting all the other "compat" stuff up
> there
* Doug ([EMAIL PROTECTED]) [990817 03:40]:
> In case anyone cares I'd like to put in a vote for compat.linux.
>From the design standpoint this balances the needs of prominence and clean
>top level name space nicely.
Count me as another in favor of Mike's explanation.
Like Mike said, there
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> In case anyone cares I'd like to put in a vote for compat.linux.
>> >From the design standpoint this balances the needs of prominence and clean
>> top level name space nicely.
>
>And in case it's not clear from the exposition in my messag
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> I think that is too obscure considering the exposure this will get.
>
>What "exposure"? It's a backend to a tuning interface for our ABI
>compatibility...
We will be judged on how well we run linux more than many other sane
factors in the f
Brian F. Feldman scribbled this message on Aug 16:
> > be used as justification for putting all the other "compat" stuff up
> > there too. I think it's a slippery slope.
>
> much as possible. Just like the ports, it makes things easier on
> everyone if we use lower-case (compat.linux, compat.ibc
Mike Smith scribbled this message on Aug 16:
> >From the perspective of an integrated namespace, we've already made the
> wrong moves insofar as vm.* should be kern.vm.*, vfs.* should be
> kern.vfs.*, etc. Either the entire kernel namespace should have a
> presumed leading kern. (and the exist
On Mon, 16 Aug 1999, Mike Smith wrote:
> > In case anyone cares I'd like to put in a vote for compat.linux.
> > >From the design standpoint this balances the needs of prominence and clean
> > top level name space nicely.
>
> And in case it's not clear from the exposition in my message to Po
> In case anyone cares I'd like to put in a vote for compat.linux.
> >From the design standpoint this balances the needs of prominence and clean
> top level name space nicely.
And in case it's not clear from the exposition in my message to Poul, I
would find this most agreeable too.
--
In case anyone cares I'd like to put in a vote for compat.linux.
>From the design standpoint this balances the needs of prominence and clean
top level name space nicely.
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, 16 Aug 1999, Jordan K. Hubbard wrote:
> I kinda like the idea of a top-level compat category; it will keep the
> top level uncluttered when sysv and iBCS compatibility start requiring
> their own knobs, and if you put linux at the top level this will later
> be used as justification for p
> > Given that "ABI" is a bit obscure, kern.compat is the only sensible
> > choice.
>
> One one hand you're right (it is a compatibility stub) but OTOH it is also
> a kernel module... ;-)
>
> Perhaps modules like this will want to have their stuff in BOTH places,
> i.e. in kernel.compat and in
On Mon, 16 Aug 1999, Mike Smith wrote:
> > > Yes, this is very true. But I think we are fooling ourselves if we
> > > believe linux emulation will not become 'standard' in the near future.
> > > Then we'll kick ourselves for giving the sysctl's convoluted names :-)
> >
> > Yeah...
> >Given that "ABI" is a bit obscure, kern.compat is the only sensible
> >choice.
>
> I think that is too obscure considering the exposure this will get.
What "exposure"? It's a backend to a tuning interface for our ABI
compatibility...
> It doesn't really matter much what we feel about it,
I kinda like the idea of a top-level compat category; it will keep the
top level uncluttered when sysv and iBCS compatibility start requiring
their own knobs, and if you put linux at the top level this will later
be used as justification for putting all the other "compat" stuff up
there too. I th
Mike Smith wrote:
> > > Yes, this is very true. But I think we are fooling ourselves if we
> > > believe linux emulation will not become 'standard' in the near future.
> > > Then we'll kick ourselves for giving the sysctl's convoluted names :-)
> >
> > Yeah... Then, the next in line
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> > Yes, this is very true. But I think we are fooling ourselves if we
>> > believe linux emulation will not become 'standard' in the near future.
>> > Then we'll kick ourselves for giving the sysctl's convoluted names :-)
>>
>> Ye
> > Yes, this is very true. But I think we are fooling ourselves if we
> > believe linux emulation will not become 'standard' in the near future.
> > Then we'll kick ourselves for giving the sysctl's convoluted names :-)
>
> Yeah... Then, the next in line after "linux" are: ibcs2 an
Matthew Dillon wrote:
> :Well, it's also a module, so perhaps we should create the whole subtree
> :for modules (as was already discussed several times..)
>
> Yes, this is very true. But I think we are fooling ourselves if we
> believe linux emulation will not become 'standard' in the n
:
:Yeah... Then, the next in line after "linux" are: ibcs2 and svr4 and
:whatever comes next. Can you live with them as main sysctl categories?
:
:Andrzej Bialecki
I think Solaris has a chance, but I doubt any other traditional vendor
UNIXes do. So it comes down to Solaris and Linux for
On Mon, 16 Aug 1999, Matthew Dillon wrote:
>
> :
> :On Sun, 15 Aug 1999, Matthew Dillon wrote:
> :
> :> :>2) under "kern.emu.linux"
> :> :>3) under "linux"
> :> :
> :> :I vote for 3.
> :> :
> :> :--
> :> :Poul-Henning Kamp FreeBSD coreteam member
> :> :[EMAIL PROTECTED]
:
:On Sun, 15 Aug 1999, Matthew Dillon wrote:
:
:> :>2) under "kern.emu.linux"
:> :>3) under "linux"
:> :
:> :I vote for 3.
:> :
:> :--
:> :Poul-Henning Kamp FreeBSD coreteam member
:> :[EMAIL PROTECTED] "Real hackers run -current on their laptop."
:> :FreeBSD -- It will
On Sun, 15 Aug 1999, Matthew Dillon wrote:
> :>2) under "kern.emu.linux"
> :>3) under "linux"
> :
> :I vote for 3.
> :
> :--
> :Poul-Henning Kamp FreeBSD coreteam member
> :[EMAIL PROTECTED] "Real hackers run -current on their laptop."
> :FreeBSD -- It will take a long t
Brian F. Feldman writes:
> On Sun, 15 Aug 1999, Warner Losh wrote:
>
> > In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> > : I suppose, but wouldn't the proper place be under machdep? I agree that
> > : a linux top-level MIB would be easiest to remember.
> >
> > Linux isn'
"Brian F. Feldman" wrote:
> > : I suppose, but wouldn't the proper place be under machdep? I agree that
> > : a linux top-level MIB would be easiest to remember.
> >
> > Linux isn't machdep. It is MI since we could have Linux/Alpha or
> > Linux/MIPS emulators...
>
> Well then, we need to move i
On Sun, 15 Aug 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : I suppose, but wouldn't the proper place be under machdep? I agree that
> : a linux top-level MIB would be easiest to remember.
>
> Linux isn't machdep. It is MI since we could have Linux/A
In message <[EMAIL PROTECTED]> Mike Smith writes:
: We're staying away from the term "emulation" because it's being
: associated with things like the abominable 'lxrun' and virtual-machine
: emulators like VMware.
Also, there is a perception that "emulation" is slower than native,
which isn't t
In message <[EMAIL PROTECTED]> "Brian F.
Feldman" writes:
: I suppose, but wouldn't the proper place be under machdep? I agree that
: a linux top-level MIB would be easiest to remember.
Linux isn't machdep. It is MI since we could have Linux/Alpha or
Linux/MIPS emulators...
Warner
To Unsubsc
> Hi,
>
> There're a couple of variables in the Linuxulator that can be put under
> sysctl. These include the kernel version and the OSS version, among
> probably others.
>
> The question is simply were in the MIB to put them?
> 1) under "kern.linux"
> 2) under "kern.emu.linux"
> 3) under "linux
In message <[EMAIL PROTECTED]>, "Brian F.
Feldman" writes:
>On Sun, 15 Aug 1999, Poul-Henning Kamp wrote:
>
>> >The question is simply were in the MIB to put them?
>>...
>> >3) under "linux"
>>
>> I vote for 3.
>
>I suppose, but wouldn't the proper place be under machdep? I agree that
>a linux t
On Sun, 15 Aug 1999, Poul-Henning Kamp wrote:
> >The question is simply were in the MIB to put them?
>...
> >3) under "linux"
>
> I vote for 3.
I suppose, but wouldn't the proper place be under machdep? I agree that
a linux top-level MIB would be easiest to remember.
>
> --
> Poul-Henning Kam
:>2) under "kern.emu.linux"
:>3) under "linux"
:
:I vote for 3.
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED] "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!
Ditto. Linux emulation
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes:
>Hi,
>
>There're a couple of variables in the Linuxulator that can be put under
>sysctl. These include the kernel version and the OSS version, among
>probably others.
>
>The question is simply were in the MIB to put them?
>1) under "kern.lin
Hi,
There're a couple of variables in the Linuxulator that can be put under
sysctl. These include the kernel version and the OSS version, among
probably others.
The question is simply were in the MIB to put them?
1) under "kern.linux"
2) under "kern.emu.linux"
3) under "linux"
4) non of the abov
35 matches
Mail list logo
