>
> After the upgrade to r205248, the script
> freezes at seemingly random points.
The script is pretty disk intensive. How long do you wait before
giving up on output?
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-current@freebsd.org maili
LF
specification. That's why it's not mentioned. Dynamic linking needs
special headers and/or sections in the ELF file to make it work.
I don't think you can infer from the ELF specification that static
linking is undefined.
--
Marcel Moolenaar USPA: A-39004 [EMAI
se specific constraints on the
construction of programs that can employ dlopen() and its related
services.
\end{quote}
> I'll also point out that the ELF specification does not define static
> linking *at all*.
I think that's because it doesn't need any special mention.
Note th
Under restricted and controlled conditions you can make it work.
I would call it the ability to have plugins, not the ability to
load dynamic libraries.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
e/init anyway. A dynamicly linked /sbin/init just
makes it harder to get to the rescue bits, so it makes sense to
link init(8) staticly. Especially since there's no advantage to
dynamic linking init(8) that compensates for the inconvience.
--
Marcel Moolenaa
On Sat, Nov 15, 2003 at 11:17:00PM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "David O'Brien" <[EMAIL PROTECTED]> writes:
> : On Sat, Nov 15, 2003 at 03:16:03PM -0800, Marcel Moolenaar wrote:
> : > Provided that we
&
number when we release.
E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
0dc14000, 0xa0002037b4e8, 0x5, 0xe45e66b8)
at syscall+0x470
epc_syscall() at epc_syscall+0x180
db>
This is on:
FreeBSD pluto1.freebsd.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Nov 12 04:49:46 PST
2003 [EMAIL PROTECTED]:/p/obj/p/src/sys/PLUTO1 ia64
--
Marcel Moolenaar US
> changes to sysinstall. GPT partitions use /dev/ad0pX while
> MBR slices use /dev/ad0sX. Both are created in the fdisk
> part of sysinstall.
Yup, my bad. I'll make the code ia64 specific.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
0046e8528) at net_init_domain+0x170
net_add_domain(0xe46c6208, 0xe4291050) at net_add_domain+0x100
mi_startup(0xe45fcce0, 0xe4703260, 0xe4703268, 0x1) at
mi_startup+0x2e0
ia64_init(0xe471c838) at ia64_init+0xca0
__start() at __start+0xa0
db>
--
ircumstances are you to break the development environment
gratuitously and turn it into a political event that allows you to
draw attention (obviously) to your (obvious) thoughts.
END OF LINE
-- Master Control, TRON
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
eady be a tier 2 platform and sparc64
is still on its way up ... sort of.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
o ask?
>
> Can any one help me?
Feel free to send the questions to [EMAIL PROTECTED] or otherwise to me.
The list is preferred because it's archived (which may also be a reason
for people to not ask the questions there :-)
BTW: What do you mean with "halt syscalls"?
--
cannot use C99 as a basis to explain the
any behaviour of the compiler in the context of the non-compliant
construct. The creation of single-element array instead of
the declared zero-element array is downright broken.
My $0.02
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTE
0 lenth, or 1?
>
> % char array[];
>
> % nm icc.o
> 0001 C array
Interesting, What does icc do with:
struct {
int tag;
char obj[];
} foo;
And what does the sizeof() operator give.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
_
iffers from ours and to
what extend and how it affects us and provided of course we can
live with whatever it is that's worse of just different from what
we have now.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote:
>
> I guess the correct question to be asking is "does the ELF format allow
> 0-length symbols?"
Of course. What size do you think a label should have otherwise?
--
Marcel Moolenaar USPA: A-39004
eate 4 arrays (*w0,
*w1, *w2 and *w3), each with a maximum of 64K and corresponding to the
4 16-bit words that constitutes a single 64-bit entity.
In this case
0006 C FOOBARw0
C FOOBARw1
C FOOBARw2
0000 C FOOBARw3
If the compiler creates arrays of
24:43 athlon kernel: done
Both drives function without problems when they are probed. I
wanted to collect more data before sending out mail, but seeing
your mail, I might as well chime in now :-)
FYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
__
ay that sigacts is not recursed, but sigacts is already a non
> recursive lock. Do you have local diffs to HEAD?
Argh, yes. I thought the behaviour was identical to the copyout()
case, otherwise I wouldn't have reported it. I missed the unlock
on line 921. My bad, sorry,
--
Marcel Moole
7f0
ast(0xa0002308d400) at ast+0x820
:
FYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
On Sat, Aug 02, 2003 at 01:53:31AM -0700, Terry Lambert wrote:
> Marcel Moolenaar wrote:
> > But if we only use the dynamic allocation then it can only fail for
> > a combination of 3rd party code.
>
> You meant to say static here, e.g. when there are two libraries
&
On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote:
> On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
>
> > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote:
> >
> > > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs
> > >
ase that causes
problems is when an existing LDT entry is overwritten by another
consumer.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
to use your head instead of your keyboard.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
() and suword32()
> I'm not sure what it would be on other architectures
fuword64 and suword64. PowerPC is like i386.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.fr
by enforcing an ordering. Make variants
like clearmake may not be tricked that easily, because they keep
track of much more.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.or
On Wed, Jul 16, 2003 at 01:59:44AM -0700, Kris Kennaway wrote:
> On Wed, Jul 16, 2003 at 12:43:37AM -0700, Marcel Moolenaar wrote:
> > On Tue, Jul 15, 2003 at 10:16:01PM -0700, Kris Kennaway wrote:
> > > >
> > > > malloc, you say? I have build failures in XF
On Wed, Jul 16, 2003 at 01:52:28AM -0700, Kris Kennaway wrote:
> On Wed, Jul 16, 2003 at 12:43:37AM -0700, Marcel Moolenaar wrote:
> > On Tue, Jul 15, 2003 at 10:16:01PM -0700, Kris Kennaway wrote:
> > > >
> > > > malloc, you say? I have build failures in XF
the default case for escaped characters, which also
incremented the pointer p beyond the terminating '\0'.
Oh: this goes to devel/imake-4 of course.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
--- ../extras/rman/rman.c.orig Tue Jul 15 23:53:53 200
malloc
> debugging problem that was introduced somehow.
malloc, you say? I have build failures in XFree4-clients because
rman coredumps and I have a backtrace full of free() frames...
Coincidence?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
__
On Tue, Jul 15, 2003 at 09:35:43PM +0200, Harti Brandt wrote:
> On Tue, 15 Jul 2003, Marcel Moolenaar wrote:
>
> MM>On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote:
> MM>
> MM>> There's not much more I can say about it until I see the full
&
On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote:
> Marcel Moolenaar <[EMAIL PROTECTED]> writes:
> > It needs to be analyzed because cross-builds should not fail. Do
> > we have a machine problem? What exactly is dumping core? Is it
> > gzip or some
words: what the fuck is going on and why doesn't anybody do
something about it?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
On Mon, Jul 14, 2003 at 10:43:33AM -0700, Nate Lawson wrote:
> > >
> > > A fix has been tested and committed.
> >
> > dmobject.c has not been added to sys/conf/files.*
>
> Thanks, that has been committed.
Thanks :-)
--
Marcel Moolenaar USP
working that I am looking into now.
>
> A fix has been tested and committed.
dmobject.c has not been added to sys/conf/files.*
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.
ossibly the only way to implement this
> numeric_limits::digits thing without any type introspection which
> C++ currently
> lacks.
What about?
#define issigned(T) (((T)(0)>(T)(~0)) ? 1 : 0)
--
Marcel Moolenaar USPA
27;ll give FreeBSD/ia64 a shot.
>
>We probably need to talk then, because the ptrace interface needs
>to be fleshed out and I planned to do that while porting gdb.
>
> Probably. The current layout of `struct reg' and `struct fpreg' is a
> bit ... me
code 2
This is a cross-build bug that's also causing non-cross buildworld
failures on ia64. Hang on...
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ll give FreeBSD/ia64 a shot.
We probably need to talk then, because the ptrace interface needs
to be fleshed out and I planned to do that while porting gdb.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pect this to be a one-man show. We
really need to treat this as a project.
Thoughts?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To
(cpu->number == PCPU_GET(cpu_number))
Agreed.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
not
> actually work.
The bogosity is in MI code. Not being able to support 64-way (or higher)
XYZ machines because MI code uses 32-bit bitmaps is wrong. Both the type
and the access to it should be abstracted in MI code to allow for
compound types. Much akin to sigset_t.
--
Marcel Moolenaar
necessary. The
> system compiler upgrade is in 5.2 TODO list.
Yay!
Do you have a p4 branch people can use to try it out on various
platforms? I very much like to build a release with it and have
it verified to run on ia64 before it hits the tree and we find
ourselves cornered.
--
Marcel Mool
this for other to decide, unless there's only 1 build tool we need
to handle for rescue and we can solve our problem by using the shell
script instead of adding make logic.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
__
e bits itself.
We could possibly copy the object directory of those tools that
have build tools, but if there are paths embedded in generated
scripts, we have to regenerate them anyway.
What about this: rebuild the build tools to get things sorted
out and working and then look if we can optimi
built *after* the cross-
tools are installed, you'll have a hard time resolving the phase
ordering problem.
That's why ru@ suggested to add a build-tools target. That way you
populate the seperate tree in sync with the phases of a world,
thereby avoiding the phase ordering problem.
FY
r code 1
Already fixed.
Note that fuword16() and suword16() are still unimplemented.
FYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
er to it in a way compatible with the runtime spec.
The dynamic TLS model requires more substantial changes and involves
RTLD as well. This is the model that requires __tls_get_addr().
\end{quote}
HTH,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
Would someone please tell me exactly what stupid thing I'm doing today?
You forgot to search the mailing list :-)
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/l
==
>
> Any hint?
Broken sed(1), I think. Has been fixed last week.
If you did a -DNOCLEAN build, don't. Otherwise, build and install sed
first.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[
#x27;t change the intline.
Sounds reasonable. I can test the code. Without the logic the BigSur I
have wont boot, so I know immediately if the additional test breaks
anything, although I'm pretty sure it wont.
--
Marcel Moolenaar USPA: A-39004
uires
> entries for sc0 and fd0.
Of which sc0 is a bogus requirement.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
use cp(1). When source files are read-only, such as for
perforce trees, a buildworld -DNOCLEAN can fail because the copy in
the object directory will be read-only too. Use cat(1) or something
else that yields a copy that is writable.
Thanks,
--
Marcel M
Probably not a good idea. You're much better off implementing it
on your own. Your requirements are likely to be different from
those of the kernel.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
n ia64
because /boot is the mount point for the EFI filesystem where we
have the kernel and modules. This is standard behaviour and one
of the cases Peter mentioned.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
e is valid or invalid when you're not acting
upon it anyway? One can even claim that emitting an error or warning *is*
reaction upon the directive.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
etter to have it fail when somebody does
use a different compiler. I think the discussion that it will trigger
will yield a less gratuitous convention. Possibly documented. YMMV.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
7;m probably going to switch
window manager and see if that makes a difference. For some reason
I'm suspicious about Metacity. Not necessarily because of this...
JFYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
et in the parent directory)?
Q: Why not use install (which in that phase will be the install
script under tools in the source directory)?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current&q
t to compile or figuring out
if you should replace all slash options for dash options, you can
pretty much focus on the compiler itself from the word go.
Needless to say that for OW I'm going to piggyback the Linux port.
TenDRA has a higher chance of being able to compile world and kernel
I think
On Sun, Mar 02, 2003 at 02:25:55PM -0700, Scott Long wrote:
>
> RE@ had in principal agreed with this work, since it will make 5-STABLE
> and 6-CURRENT more compatible.
That's all I wanted to know. Thanks,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
On Sun, Mar 02, 2003 at 09:26:31PM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes
> :
> >On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote:
> >>
> >> I plan to commit
> >>http://phk.freebs
59 lines of redundant defaultvalue
> initializations.
I thought HEAD was in a slush mode. des' sweep and this sweep seems
like the kind of changes we don't want at this time. Has this changed
or did re@ approve it (both cases)?
--
Marcel Moolenaar USPA: A-39004
On Sat, Mar 01, 2003 at 12:23:22PM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Marcel Moolenaar <[EMAIL PROTECTED]> writes:
> : BTW: Shouldn't we obsolete wicontrol then or strip functionality?
> : It appears we have 2 ways in which we
On Sat, Mar 01, 2003 at 06:08:27AM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Marcel Moolenaar <[EMAIL PROTECTED]> writes:
> : > status: no carrier
> : > ssid "" 1:""
> :
> : Did you do `wicontrol -i wi0
carrier
> ssid "" 1:""
Did you do `wicontrol -i wi0 -p 1'?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ve driver-private > versions. > > Is this more clear
> now?
>
> Crystal :-)
>
> Heh, I hope I didn't sound too forceful. It was just a straightforward
> question, not a diatribe. :)
No worries. It's too late to realize that there might b
ther issues with the latest wi driver. :-(
The attached patch fixes the device timeout problem. I don't claim
it is correct, but may serve as the basis for experimentation (is
it the limit of 10 iterations, is it the fiddling with status bits
or something else).
--
Marcel Moolenaar
4 bit endian
> conversions in both aligned and unaligned access forms. After these functions
> are there, I'd like us to unify use of them and remove driver-private
> versions.
>
> Is this more clear now?
Crystal :-)
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTE
antage to moving the geom byte ordering functions to
> (I guess phk didn't either).
The geom functions serve a primary purpose of dealing with random
alignment of fields. The endianness has been added later, so they
now serve a dual function. Do not unify them with byte-order only
funct
I think the important part is setting
expectations right. People should not expect 5.x to run on
80386, so that casual users don't waste their time. People who
really know what they are doing can probably get it to work and
I think that fixes, within reason, are acceptable as well...
--
good to add to your release cycle something you don't
build/validate during development. Releases are painful enough
that you don't want to turn them into testbeds. If it's not
worth testing during development, it's not worth releasing...
--
Marcel Moolenaar USPA: A-
rspace from dump, or kernel process---
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
t,
> but I'd like if some of you can give it a spin too:
>
> http://phk.freebsd.dk/patch/console.patch
>
> The patch just does the not quite mechanical switch, some of the drivers
> could get some mileage from the cn_arg field but I have not tried that.
I'll test
-current
that you at least be on -current (the commit bit is optional,
the mailinglist subscription is not :-)
Something like that. No written-down rules AFAICT, but just plain
common sense.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, Jan 30, 2003 at 10:09:57AM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Marcel Moolenaar <[EMAIL PROTECTED]> writes:
> : general theme. Thus (in this case), ARCH=mips and MACH=algor or
> : MACH=sgimips...
>
> Actually, NetBS
ings that want it. Does that work for you?
Yes.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, Jan 29, 2003 at 12:55:30PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-29 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > > If we just make "machine" mean more of what it mean
forms. If we can handle such a
case then nothing is lost if we don't make use of it for i386.
> If we just make "machine" mean more of what it means now, then we're
> set.
But pc98 needs to be dealt with. Maybe a summary of what's been
discussed would be a good idea.
re we run the config(8)
utility from later. We can always add the necessary options and
keywords to deal with the added flexibility, including making the
architecture explicit. In that case it would work the same on all
architectures without any weird interferences of having multiple
platforms.
Thoughts?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, Jan 28, 2003 at 11:56:59PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > You see how the current approach affects other architectures if you
I sent that in my
reply to Benno.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
c and mips.
> Or are you saying that you would prefer to change how the machine
> directive works in config(8) and introduce a new "non-standard"
> directive for pc98?
That was the thought I was playing with.
> If the former, I agree totally. If the latter, I'm not so
through. The point is
that I didn't spend the time and that I have in my head this
notion that it makes sense in some other way. I think I did
my best to get us in line in an attempt to find mutual
understanding. I don't feel responsible for you perceiving it
as bikeshedding. If it was, pleas
at we
do mips and powerpc different, I think we should say that mips and
powerpc do it the normal way and pc98 does it differently. I like
to use an extra keyword for the weird case (pc98) and not the normal
(common) case. See also above, this is looking at it from a point
of view we'll going t
impress me.
In fact it only tells me that you're incapable of convincing me
and that you're incapable of looking at it from my point of view
and tell me where I'm missing something. No, you're fixated and
it took a lot of effort from my end to get to a point where we
unde
ew variable if it's too hard to
do it without, but I think there's a more logical/optimal scheme
of naming and attaching meaning that does not affect the common
case (it only affects pc98).
> affects those explicit consumers of it. The more we discuss
> making "machine" a
On Tue, Jan 28, 2003 at 07:01:58PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > > > > We attach lots of meaning to MACHINE. You keep m
On Tue, Jan 28, 2003 at 06:20:13PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > > No, we have not established that.
> >
> > *s
On Tue, Jan 28, 2003 at 05:42:59PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > On Tue, Jan 28, 2003 at 04:49:55PM -0800, Juli Mallett wrote:
>
the meaning it must have in order to solve the mips/powerpc
problem? Or do we not attach a certain meaning to MACHINE that we
should attach to it?
For example: When building world, we can test for MACHINE_ARCH and
MACHINE. Do you need to select a (default) compiler target based on
MACHINE o
On Tue, Jan 28, 2003 at 04:09:36PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote:
On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote:
> * De: Marcel Moolenaar <[EMAIL PROTECTED]> [ Data: 2003-01-28 ]
> [ Subjecte: Re: Patch to teach config(8) about "platforms". ]
> > > I just really would like things to be clean, and abstracted, an
HINE and it looks to me that MACHINE can
do what you try to achieve with platform. Why add a "platform"
keyword to config(8) if we already have the "machine" keyword?
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
he problem.
I don't have more details right now, but may get back to this
later.
JFYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
s is probably that any PnP id will do as long as you
have hints and you use a PnP id that is tried on the psm driver...
This may be specific to psm, though. If you're interested, try removing
the hints and see if it still works without the right PnP id (see
/boot/device.hints).
--
Marcel Moo
A Sony
specific PnP id is 0xd94d... Your Id is one for an ACPI embedded
controller and I don't think it has to be a mouse. I suspect there's
a _CID value as well and that it's a generic PS/2 mouse id...
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsu
e failed attempt to probe the PS/2 mouse given the unrecognized
PnP id that we obtain from ACPI and the freaky behaviour of psm(4)
to reserve the IRQ in case it's being probed before atkbdc(4) is
probed. Removal of the hints suppresses the IRQ failure and yields
a silent misprobe...
--
Marc
definition of _HID is
the PnP id that you need to add. It probably is 0x0190d94d in
your case. You can add the PnP id, or checkout -rHEAD, because
it's fixed already.
HTH,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
101 - 200 of 512 matches
Mail list logo
