> On Thursday 15 December 2005 03:49 pm, Matt Emmerton wrote:
> > I know this has been discussed ad nauseum, but here's my $0.02:
> >
> > Why not mark these entries as 'mandatory' in /usr/src/sys/conf/files*
> > instead?
> > This will cause config to error out if they are not specified in the
> > c
On Thursday 15 December 2005 03:49 pm, Matt Emmerton wrote:
> I know this has been discussed ad nauseum, but here's my $0.02:
>
> Why not mark these entries as 'mandatory' in /usr/src/sys/conf/files*
> instead?
> This will cause config to error out if they are not specified in the
> config, and han
>on 30.10.2005 11:36 Uhr Cristiano Deana said the following:
>> Hi,
>>
>> I've seen that 'GENERIC' file has been modified, moving some lines to
>> 'DEFAULTS':
>>
>> device isa
>>
>> device mem # Memory and kernel memory devices
>> device io # I/O
Kris Kennaway wrote:
> You've clearly never spent much time on the
> FreeBSD support forums, where every few days
> someone posts for help
>
> 1) with an error caused by removing one of those
> "Do not remove this!" lines, and
>
> 2) for help on getting X working when they forgot
> to add /dev/i
Robert Watson wrote:
> My hope is that, increasingly, FreeBSD users will create kernel
> configuration files using the "include" directive to specify a set of
> changes relative to GENERIC. That will also help lower the rate of foot
> shooting involving kernel components becoming optional. Most
On Thu, Nov 03, 2005 at 09:27:02AM -0500, John Nielsen wrote:
> On Thursday 03 November 2005 09:03 am, Ruslan Ermilov wrote:
> > On Thu, Nov 03, 2005 at 12:27:21PM +, Robert Watson wrote:
> > > On Thu, 3 Nov 2005, dick hoogendijk wrote:
> > > >Sure, but I think it's the *syntax* that matters he
On Thursday 03 November 2005 09:03 am, Ruslan Ermilov wrote:
> On Thu, Nov 03, 2005 at 12:27:21PM +, Robert Watson wrote:
> > On Thu, 3 Nov 2005, dick hoogendijk wrote:
> > >Sure, but I think it's the *syntax* that matters here? options ->
> > >nooptions / i486_cpu -> no??? It's OK to leave GEN
On Thu, Nov 03, 2005 at 12:27:21PM +, Robert Watson wrote:
>
> On Thu, 3 Nov 2005, dick hoogendijk wrote:
>
> >Sure, but I think it's the *syntax* that matters here? options ->
> >nooptions / i486_cpu -> no??? It's OK to leave GENERIC alone, but HOW
> >are things switched off?
>
> It appea
dick hoogendijk wrote:
On Wed, 02 Nov 2005 23:27:15 +0100
Philippe PEGON <[EMAIL PROTECTED]> wrote:
Ken Menzel wrote:
options INVARIANT_SUPPORT
nooptions WITNESS
nooptions WITNESS_SKIP_SPIN
If I include GENERIC can I comment out the following?
#cpuI486_CPU
#cpu
On Thu, 3 Nov 2005, dick hoogendijk wrote:
Sure, but I think it's the *syntax* that matters here? options ->
nooptions / i486_cpu -> no??? It's OK to leave GENERIC alone, but HOW
are things switched off?
It appears to be an ommission in the file format. I've e-mailed Ruslan,
who implemente
On Wed, 02 Nov 2005 23:27:15 +0100
Philippe PEGON <[EMAIL PROTECTED]> wrote:
> Ken Menzel wrote:
> >> options INVARIANT_SUPPORT
> >>
> >> nooptions WITNESS
> >> nooptions WITNESS_SKIP_SPIN
> >
> >
> > If I include GENERIC can I comment out the following?
> > #cpuI486_CPU
> > #
On 03/11/2005, at 9:09 AM, David Wolfskill wrote:
On Wed, Nov 02, 2005 at 04:39:30PM -0500, Ken Menzel wrote:
...
If I include GENERIC can I comment out the following?
#cpuI486_CPU
#cpuI586_CPU
Well, it's your (copy of) the file; I suppose you can do whatever you
wan
Ken Menzel wrote:
options INVARIANT_SUPPORT
nooptions WITNESS
nooptions WITNESS_SKIP_SPIN
If I include GENERIC can I comment out the following?
#cpuI486_CPU
#cpuI586_CPU
Does this make any difference? I have always done this out of habit.
would it become
in
On Wed, Nov 02, 2005 at 04:39:30PM -0500, Ken Menzel wrote:
> ...
> If I include GENERIC can I comment out the following?
> #cpuI486_CPU
> #cpuI586_CPU
Well, it's your (copy of) the file; I suppose you can do whatever you
want to with it. :-)
> Does this make any differ
options INVARIANT_SUPPORT
nooptions WITNESS
nooptions WITNESS_SKIP_SPIN
If I include GENERIC can I comment out the following?
#cpuI486_CPU
#cpuI586_CPU
Does this make any difference? I have always done this out of habit.
would it become
nocpu I486_CPU ?
Or
On Nov 2, 2005, at 2:43 AM, Rob wrote:
My point is then to follow this strategy also for X:
instead of a DEFAULTS file, have a /etc/rc.d/xdm
script, which starts X and loads the modules io/mem
if needed.
but these devices are also needed for things like netstat. you
pretty much need to lo
On Wed, 2 Nov 2005, Rob wrote:
Kris Kennaway wrote:
You missed the part where I said that the error is commonly reported by
people who have chosen not to build modules.
The DEFAULTS construction is put in place to help 'novices' not to do
stupid things (as removing io/mem).
However, doe
Kris Kennaway wrote:
>
> You missed the part where I said that the error is
> commonly reported by people who have chosen not to
> build modules.
The DEFAULTS construction is put in place to help
'novices' not to do stupid things (as removing
io/mem).
However, does 'building a kernel without mod
On Tue, 1 Nov 2005 23:43:29 -0800 (PST)
Rob <[EMAIL PROTECTED]> wrote:
> My point is then to follow this strategy also for X:
> instead of a DEFAULTS file, have a /etc/rc.d/xdm
> script, which starts X and loads the modules io/mem
> if needed.
Not everybody uses xdm, some use the KDE vers
On Tue, Nov 01, 2005 at 11:43:29PM -0800, Rob wrote:
> Kris Kennaway wrote:
> >
> > You've clearly never spent much time on the FreeBSD
> > support forums, where every few days someone posts
> > for help
> >
> > 1) with an error caused by removing one of those
> > "Do not remove this!" lines, and
2005/11/1, Scott Long <[EMAIL PROTECTED]>:
> The future direction is that FreeBSD will continue to be friendly to
> novice users while still affording power users the control that they
> seek.
Scott, that's right.
but: we can have our personal way to shoot in the foot, we can use
big, BIG, advic
Kris Kennaway wrote:
>
> You've clearly never spent much time on the FreeBSD
> support forums, where every few days someone posts
> for help
>
> 1) with an error caused by removing one of those
> "Do not remove this!" lines, and
>
> 2) for help on getting X working when they forgot
> to add /dev/
On 10/31/05, Scott Long <[EMAIL PROTECTED]> wrote:
> The future direction is that FreeBSD will continue to be friendly to
> novice users while still affording power users the control that they
> seek. This feature is not going to be a dumping ground of dubious
> and secret options that are impossi
Pete Slagle wrote:
i agree 100%, i hate wizardy/black-magic, and this 'fix' falls in that
class. Why was a 5ton hammer used to fix non existing problem?
a small comment like 'you better keep these lines to make X happy'
would have sufficed.
You've clearly never spent much time on the FreeBSD
On Mon, Oct 31, 2005 at 03:46:56PM -0800, Pete Slagle wrote:
> >>i agree 100%, i hate wizardy/black-magic, and this 'fix' falls in that
> >>class. Why was a 5ton hammer used to fix non existing problem?
> >>a small comment like 'you better keep these lines to make X happy'
> >>would have sufficed.
i agree 100%, i hate wizardy/black-magic, and this 'fix' falls in that
class. Why was a 5ton hammer used to fix non existing problem?
a small comment like 'you better keep these lines to make X happy'
would have sufficed.
You've clearly never spent much time on the FreeBSD support forums,
where
At 12:01 PM +0200 2005-10-31, Danny Braniss wrote:
> you probably know many scenarios that i - thankfully - am no
> aware of, but by creating the magic DEFAULTS file the problem
> still exits! What will prevent from Joe Shootmyfoot to comment out
> the lines in DEFAULTS?
chflags
> At 11:18 AM +0200 2005-10-31, Danny Braniss wrote:
>
> > you probably know many scenarios that i - thankfully - am no
> > aware of, but by creating the magic DEFAULTS file the problem
> > still exits! What will prevent from Joe Shootmyfoot to comment out
> > the lines in DEFAULTS?
>
>
At 11:18 AM +0200 2005-10-31, Danny Braniss wrote:
you probably know many scenarios that i - thankfully - am no
aware of, but by creating the magic DEFAULTS file the problem
still exits! What will prevent from Joe Shootmyfoot to comment out
the lines in DEFAULTS?
chflags schg DEFAU
[...]
> Many users who build custom kernels do not build modules, since they
> want to compile everything they (think they) need into the kernel
> statically.
you probably know many scenarios that i - thankfully - am no
aware of, but by creating the magic DEFAULTS file the problem
still exits! What
On Mon, Oct 31, 2005 at 10:46:37AM +0200, Danny Braniss wrote:
>
> > You've clearly never spent much time on the FreeBSD support forums,
> > where every few days someone posts for help
> >
> > 1) with an error caused by removing one of those "Do not remove this!"
> > lines, and
> >
> > 2) for he
> You've clearly never spent much time on the FreeBSD support forums,
> where every few days someone posts for help
>
> 1) with an error caused by removing one of those "Do not remove this!"
> lines, and
>
> 2) for help on getting X working when they forgot to add /dev/io and
> /dev/mem to their
On Mon, Oct 31, 2005 at 10:12:01AM +0200, Danny Braniss wrote:
> i agree 100%, i hate wizardy/black-magic, and this 'fix' falls in that
> class. Why was a 5ton hammer used to fix non existing problem?
> a small comment like 'you better keep these lines to make X happy'
> would have sufficed.
You'
> >> I've seen that 'GENERIC' file has been modified, moving some lines to
> >> 'DEFAULTS':
> >>
> >> device isa
> >>
> >> device mem # Memory and kernel memory devices
> >> device io # I/O device
> >>
> >> Why?
> >> What does it mean? Should
On Sun, Oct 30, 2005 at 03:22:09PM -0800, Pete Slagle wrote:
> >>I've seen that 'GENERIC' file has been modified, moving some lines to
> >>'DEFAULTS':
> >>
> >>device isa
> >>
> >>device mem # Memory and kernel memory devices
> >>device io # I
Hi all!
Since the amount of files goes up,
there is a chance to mess something
with the best in mind. Personaly, I
like simple style of making new
kernel. Defaults? OK if works well,
without complaints for people, who
need nothing more than necessary.
What's about "compat" options for
clean instal
I've seen that 'GENERIC' file has been modified, moving some lines to
'DEFAULTS':
device isa
device mem # Memory and kernel memory devices
device io # I/O device
Why?
What does it mean? Should we include 'DEFAULTS' in our customized
'GEN
On Sun, 2005-10-30 at 12:04 +0100, Mathieu Arnold wrote:
> In that case, how do we remove io or mem so that they get in as kld at boot
> time ?
With the nodevice directive.
--
Massimo.run();
___
freebsd-stable@freebsd.org mailing list
http://lists.f
+-le 30/10/2005 11:53 +0100, Massimo Lusetti écrivait :
| On Sun, 2005-10-30 at 11:36 +0100, Cristiano Deana wrote:
|
|> Hi,
|>
|> I've seen that 'GENERIC' file has been modified, moving some lines to
|> 'DEFAULTS':
|>
|> device isa
|>
|> device mem # Memory and ke
on 30.10.2005 11:36 Uhr Cristiano Deana said the following:
Hi,
I've seen that 'GENERIC' file has been modified, moving some lines to
'DEFAULTS':
device isa
device mem # Memory and kernel memory devices
device io # I/O device
Why?
What
Thank you , Kris.
> It's included by DEFAULT.
> The point of a DEFAULTS file is that to contain things that are used
> by DEFAULT, including those which are mandatory.
As I thought, but how? I didn't see any "include" in GENERIC or any
modify in Makefile.
> > I think it should be written in 'UP
On Sun, 2005-10-30 at 11:36 +0100, Cristiano Deana wrote:
> Hi,
>
> I've seen that 'GENERIC' file has been modified, moving some lines to
> 'DEFAULTS':
>
> device isa
>
> device mem # Memory and kernel memory devices
> device io # I/O devi
On Sun, Oct 30, 2005 at 11:36:46AM +0100, Cristiano Deana wrote:
> Hi,
>
> I've seen that 'GENERIC' file has been modified, moving some lines to
> 'DEFAULTS':
>
> device isa
>
> device mem # Memory and kernel memory devices
> device io # I/
Hi,
I've seen that 'GENERIC' file has been modified, moving some lines to
'DEFAULTS':
device isa
device mem # Memory and kernel memory devices
device io # I/O device
Why?
What does it mean? Should we include 'DEFAULTS' in our customized
44 matches
Mail list logo
