is logically wrong for non-ns8250 based UARTs.
Leave the code as is.
Thanks,
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to &quo
On Nov 10, 2010, at 12:44 AM, Garrett Cooper wrote:
> On Tue, Nov 9, 2010 at 10:29 PM, Marcel Moolenaar wrote:
>>
>> On Nov 6, 2010, at 11:22 AM, Garrett Cooper wrote:
>>
>>>Some of the logic could have been simplified in the probe. The
>>> proposed
are handled by ppc(4) for parallel
ports and uart(4) for serial ports. There's no need to
have puc(4) in between.
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-h
tering the function.
As such, only virtual functions in C++ are impacted by this. The
function descriptor needs to be stored in the object instead of
the function pointer in that case.
FYI,
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-hackers@
ing to do this?
You need to support both anyways. But not at the same time.
The machine either boots BIOS or EFI and depending on that
will it use the EFI loader or use the MBR to load boot code.
There's nothing to try.
Key is to have a single kernel loadable and bootable by
either
d a clean way to convince
> the loader's ELF code to put the kernel there.
Look at what I did for ia64. All that frobbing should be done
in the machine specific implementation of arch_copyin, arch_copyout
and arch_readin. It's a kluge to do it in elf_loadimage.
FYI,
--
Marc
proven to not deliver on that.
This is actually impacting existing FreeBSD consumers already, like
Juniper. So, se should not go deeper into this rabbit hole. We should
finally solve this problem for real...
--
Marcel Moolenaar
mar...@xcllnt.net
___
e time.
I see that as a better way of looking at it than simply blurting out
that you shouldn't use gmirror when certain awkward and artifical
conditions apply.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-hackers@freebsd.org mailing list
http:/
tc) for
no apparent reason and without any kind of warning that what he/she is doing
is potentially harmful... That's the spirit!
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/
sn't the only
one. Granted, it can easily be the simplest one or even the
best one in some cases, but that's besides the point you were
making.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-hackers@freebsd.org mailing list
http://list
On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>>>
>>> GPT really wants the backup header at the last LBA. I know you can
d be discoverable by non-FreeBSD.
That clearly isn't the case -- hence it's not standards compliant. What
for example if someone wanted to share the swap partition between Linux
and FreeBSD?
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-h
On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote:
> On 27.06.2012 21:55, Marcel Moolenaar wrote:
>> You can't just re-interpret standards to match a context you know very well
>> isn't applicable and consequently redefine what the word "device" means.
>
On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote:
> On 28.06.2012 00:14, Marcel Moolenaar wrote:
>>> Our loader detects that primary GPT header is damaged. It tries to read
>>> backup GPT header from the last LBA and it detects that there is
>>> "GEOM
One violates
the spec on grounds of making the *unique* disk identifier non-unique by
presenting OSes with multiple disks that have identical IDs.
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.f
On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote:
> On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>>>
>>> All of the above is ugly, U'm afraid :(
>>
>> Ind
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
> On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar
> wrote:
>
>> My advise is to leave disk mirroring to H/W or firmware solutions and
>> use FreeBSD mirroring for FreeBSD partitions only. If you want to
>
already suggested a few things in this thread. Go read it.
I'm bored now, so I'll just wait for UEFI booting to be forced upon
those who mirror the whole disk with gmirror. I think that's when
we will have a more substantial and meaningful continuation of this
thread.
--
Marcel Mo
ing to bmake for ports.
2. In parallel with 1: build www & docs with bmake and assess the
damage
3. Fix all the damage
Then:
4. Switch.
It could be a while (many weeks) before we get to 4, so the question
really is whether the people working on ATF are willing and able to
build and instal
ntil then, the manual step is needed.
That's it...
--
Marcel Moolenaar
mar...@xcllnt.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Oct 25, 2012, at 2:15 PM, David O'Brien wrote:
> On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote:
>> two independent efforts (ATF & bmake) and there was no indication that
>> one would be greatly benefitted from the other. At least not to th
want. If you
try to allocate something that's not there, then you have a new
situation that the driver needs to know about and you code
accordingly.
HTH,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
.
In short: We do need a generic input framework, but I think we need
it in the kernel, not in user space. I also think that a generic
input layer should be capable of handling both focussed and non-
focussed input devices to lay the foundation for configurations
that do not include keyboards.
-
On Apr 17, 2007, at 3:17 PM, Maxim Zhuravlev wrote:
2007/4/17, Marcel Moolenaar <[EMAIL PROTECTED]>:
Thanks for detailed useful reply.
As for vtc(4): I've not been working on input devices because of the
lack of a generic layer. Note that vtc(4) deals with the low-level
console
work, look at TLS (more relocations) and gdb. You
may need
to review threading support...
HTH,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe
e has been made
yet.
FreeBSD actually creates a GPT with relative addresses, which means
that if we allow it to be used to sub-partition partitions, it would
not have the same problem as the BSD label.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freeb
On May 22, 2007, at 11:58 AM, Craig Boston wrote:
On Tue, May 22, 2007 at 02:34:02PM -0400, Marcel Moolenaar wrote:
GPT is not designed to be a sub-partitioning scheme. It can not be
used within a partition. As such, absolute block addresses are the
same as relative block addresses. As such
e
there's where g_part is missing features.
Keep me in the loop.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Jun 9, 2007, at 1:04 PM, Ivan Voras wrote:
Marcel Moolenaar wrote:
On Jun 9, 2007, at 9:22 AM, Ivan Voras wrote:
Another thing that would be nice to have is support for fdisk and
disklabel partitions inside geom_part, so it's management utility
can be
used for both GPT and old
LBA. In the
MBR partition you can put a GPT aware boot loader that uses the
GPT to find the real partitions...
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To un
. You can free up space for MBR partitions
:after the primary GPT table by adjusting the first LBA. In the
:MBR partition you can put a GPT aware boot loader that uses the
:GPT to find the real partitions...
:
:--
:Marcel Moolenaar
In the bootcamp approach, is the GPT (0xEE) slice the first
or read. The use
of FIFO in the uart(4) is not limited to its definition in PC
hardware.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
(i.e. zero). And it doesn't seem to get set anywhere else, either.
Uhm, on line 817 in uart_dev_ns8250.c, which falls in function
uart_bus_probe(), both the rx and tx fifo sizes are set to 1.
This is for the case there's no fifo.
FYI,
--
Marcel Moolenaar
[EMAIL
On Jun 18, 2007, at 8:56 AM, Christian Kandeler wrote:
On Monday 18 June 2007 17:39, Marcel Moolenaar wrote:
Uhm, on line 817 in uart_dev_ns8250.c, which falls in function
uart_bus_probe(), both the rx and tx fifo sizes are set to 1.
Yes, I was apparently working with an outdated release
TR)
ret = 0;
I don't know if anyone other than possibly David Xu have
tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes,
so they may not work as they're suppose to.
We use it successfully with the above patch.
FYI,
--
Marcel Moolenaar
.
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
appreciated.
I love the screenshot. I'm going to use the background in
my VTY driver as well :-)
--
Marcel Moolenaar
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Feb 20, 2008, at 4:57 AM, Oliver Fromme wrote:
Marcel Moolenaar wrote:
Oliver Fromme wrote:
It will not replace the current text menu ("beastie.4th"),
so you can still use it on your Hercules monochrome or CGA
machine or with serial console, of course.
We can probably fo
. Orders of
magnitude slower. In VGA planar modes, you have to
select each of the four bitplanes, one after another
(using inb + mask + outb to the ISA registers), in order
to set a single pixel. Doing that for every single pixel
in a character string or PCX image would be prohibitivel
hics mode,
so the loader is the place to do it. Sorry for the confusion.
PS: I just took a few minutes to make yet another screen
design, it's based on the design of the www.freebsd.og
web pages. It includes both the logo and the daemon
mascot:
http://www.secnetix.de/olli/FreeBSD/
have to care at
all and when you need to draw the line in software,
you need to test the coordinates anyway and split the
work based on angle even. In that case you also split
horizontal and vertical.
Anyway: that's enough out of me. I think what you're
doing is great and I can't wait to
0 b..." is valid C code?
Well, if b... is a preprocessor define then you can easily
come up with valid C:
#define b...*2
then: ...0 b...
becomes:...0 *2
That's a valid expression in the right context...
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
mpatibility. I think I'm going
to borrow a thought or two from Linux which allows further increasing of
the number of signals without rewriting the logic, but that's basicly
undecided yet and open for discussion.
--
Marcel Moolenaar mailto:mar...@scc.nl
S
sigset_t in
the kernel without recompilation of userland tools.
--
Marcel Moolenaar mailto:mar...@scc.nl
SCC Internetworking & Databases http://www.scc.nl/
Amsterdam, The Netherlands tel: +31 20 4200655
To Unsubs
Sheldon Hearn wrote:
>
> On Mon, 30 Aug 1999 15:55:56 +0200, Marcel Moolenaar wrote:
>
> > The Linux trick I like to add is to have sigset_t always be the last
> > field in structures so that the impact of enlarging sigset_t is
> > minimal.
>
> On LITTLE_ENDIAN
worth having __sigbits to be the size that most suits the architecture (32
for i386; 64 for alpha) because of the frequent bit manipulations that are
expected to be performed with it?
--
Marcel Moolenaar mailto:mar...@scc.nl
SCC Internetworking & Databases
< libosl516li.so.bak > libosl516li.so
> > > touch /compat/linux/so
> >
> > I don't think this one is needed anymore ?!?
>
> It is. Without it, soffice keeps bringing up setup over and over instead
> of just starting the damn office.
What is e
Mikhail Teterin wrote:
>
> Marcel Moolenaar once wrote:
>
> > > >
> > > > I don't think this one is needed anymore ?!?
> > >
> > > It is. Without it, soffice keeps bringing up setup over and over
> > > instead of just starti
Vince Vielhaber wrote:
>
> On Thu, 2 Sep 1999, Mikhail Teterin wrote:
>
> > Marcel Moolenaar once wrote:
> >
> > > > >
> > > > > I don't think this one is needed anymore ?!?
> > > >
> > > > It is. Without it, soffi
bro...@one-eyed-alien.net wrote:
>
> On Thu, 2 Sep 1999, Marcel Moolenaar wrote:
>
> > SO5.1 installs OOTB on both -current and -stable. I suspect your -stable is
> > not recent?
>
> Is this true for BOTH versions of the tarball? Changes where made to the
> dis
; requires jumping throught the hoops (unzip setup.zip, etc.) to
> install but runs OOTB after that. I havn't tried to do a
> 'network' install.
Sigh...
--
Marcel Moolenaarmailto:mar...@scc.nl
SCC Internetworking & Databases http://www.s
ways needed to do. It can't find the shared object because
it simply is not in a searchable place. Setting LD_LIBRARY_PATH solves it.
I always thought it was related to setting TMP to /var/tmp because I don't
have enough space on /.
--
Marcel Moolenaarmai
--- procfs_status.c 1999/08/28 00:46:56 1.16
+++ procfs_status.c 1999/09/04 06:32:46
@@ -199,6 +199,7 @@
ps += done;
bytes_left -= done;
}
+ ps--;
}
else {
Hi,
Another issue when sigset_t changes is the version numbers of shared
libraries. Since libc and libc_r have changed on the interface level, they
need a version bump. I assume that all others automaticly also need a
version bump then. Am I correct in this assumption?
--
Marcel Moolenaar
es.
> For GCC, __asm__ attribute also can be used.
That still is an interface change and thus needs a version bump. How else
do I know wich version x library has the new implementations (besides the
larger one :-)?
--
Marcel Moolenaarmailto:mar...@scc.nl
SCC Internetworki
Dmitrij Tejblum wrote:
>
> Marcel Moolenaar wrote:
> > > I suggest to try to avoid the version bump. NetBSD-like way to do it:
> > > Give new implementations another names in object files, so that they
> > > don't conflict with old implementations, and pre
t;you cannot have everything" and noone, I hope, will use such dlsym.
Your suggestion has more impact than that. It violates POLA. In all case a
certain function is called `foo' except in the library where it resides,
where it is called `bar'. I can imagine programmers to get really con
ies but the latest with a given major version...
Ah, well... so much for this brainwave :-)
--
Marcel Moolenaarmailto:mar...@scc.nl
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:mar...@freebsd.org
To Unsubscr
; certain function is called `foo' except in the library where it resides,
> > where it is called `bar'. I can imagine programmers to get really confused
> > when their linker starts complaining about function `bar' and they simply
> > can't find a referen
every function in every library that has changed directly or
indirectly for this scheme to work.
Now, are you going to do the reimplementation for every library on this
planet just to prevent someone from recompiling his library and forgetting
to reimplement those functions that got changed indirectly
Richard Wackerbarth wrote:
>
> On Thu, 09 Sep 1999, Marcel Moolenaar wrote:
> > Sheldon Hearn wrote:
>
> > I'm more tempted to revert to the major/minor versioning. Every change
> > triggers a minor version bump, but only if the library is still backwards
> &g
o,
if you got something to say, say it now.
--
Marcel Moolenaarmailto:mar...@scc.nl
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD projectmailto:mar...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with &qu
ur solution can maintain a higher degree of compatibility
then a version dump. In both cases you can run -stable binaries on -current
but not the other way around.
> [perhaps, I will answer the rest of your mail later]
I do hope so. I think that adding functions to hide datatype changes have
Boris Popov wrote:
> Currently I'm trying to determine a reasonable set of NetWare
> utilities which should be included in the source tree.
Is it possible to have utilities to query and modify NDS?
> ncpurge - purge specified salvagable files,
directly. I'm keeping track of FreeBSD
support here:
http://wiki.freebsd.org/LowLevelVirtualMachine
What I'd like to have is some nightly automation that does the
testing across all platforms.
We could create nightly snapshots as part of the automation and
create a port that
lly is
not the way to go. Have a look at the code and see for yourself.
Yes, libdisk is bad. GEOM_PART has been designed
for use by installers. It can be interfaced
faily easily. See gpart(8) for example.
FYI,
--
Marcel Moolenaar
[EMAIL PROTECTED]
_
n that's in the XML.
Things like geometry come to mind.
But of course, you can always read the XML, use gpart(8)
to make a change and read the XML again. Having that,
it's only a tiny step to use the gctl interface directly.
FYI,
--
Marcel M
us has been doing some great work towards US-III support.
I have FreeBSD/sparc64 running on Netra SMP with US-III CPUs.
While the code is not in SVN, It's in Perforce and from what
I can see, it's in a very good shape.
FYI,
--
Marcel Moole
, will still be read
in parts.
In other words: don't use __packed when you don't have to.
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsu
ads to confusion given that puc(4) is (still) not in GENERIC.
(i.e. why is this UART attached, but that one isn't, they're
both single port?)
So, please do not apply the patch and instead add the IDs to
sys/dev/uart/uart_bus_pci.c...
FYI,
--
Marcel Moolenaar
xcl...@mac.com
On Mar 3, 2009, at 8:59 AM, John Baldwin wrote:
On Tuesday 03 March 2009 11:48:42 am Marcel Moolenaar wrote:
On Mar 3, 2009, at 6:15 AM, John Baldwin wrote:
diff -r 025cb00d19d7 sys/dev/puc/puc.c
--- a/sys/dev/puc/puc.c Sat Feb 28 12:42:37 2009 -0800
+++ b/sys/dev/puc/puc.c Mon Mar 02 12
)
I recall that our "make -j X" actually limits the number
of make processes/jobs to X. I don't know anything about
build.sh, so I don't know if our make is at all being
involved, but it would be good to know how the load varies
per OS. We may simply have less parallelism in the bu
uropean intern practice.
*plonk*
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
er platforms?
Isn't it better to do it in cpu_set_syscall_retval()?
That way you catch all cases, plus you can save the
translated error as well...
--
Marcel Moolenaar
xcl...@mac.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.fr
>
> > So what is the correct procedure for debugging Linux binaries?
>
> Have you tried the Linux gdb?
IIRC, the Linux gdb doesn't grok our core files. I started an
implementation for our Linuxulator to dump Linux compatible core files
so that you could use the Linux gdb. I gues
gh the installation process in such a
way that users get asked only those questions that are relevent and
also when it matters. One puts a UI on top of this to get a nice
looking installer. At least, that's how I look at it...
--
Marcel Moolenaar USPA: A-39004
allow multiple protocols.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
k a realclean target based on a recursive rm is
generally useful. Adding a chflags in there makes it more foolproof
and thus ideal for UPDATING and other user oriented documentation.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
_
tion then gives the above:
0 = black
1 = green
2 = red
3 = yellow
Just a thought,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/
ys/cdefs.h.
Our compiler defines __FreeBSD__. You might be able to do:
#ifdef __FreeBSD__
#include
__FBSDID("$FreeBSD$");
#endif
The advantage of something like this is that you don't spam the
library on non-FreeBSD systems. Just a thought...
--
Marcel Moolenaar USPA: A-39
c(4) is
the problem more that sio(4) or uart(4). However, uart(4) has the
beginnings of an interface that puc(4) could use to figure out
which UART needs attention without actually calling the interrupt
routine for each of them.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
_
vided the host and target
architectures are the same.
In short: try it. chances are it works. If not, try with a cross-gdb.
HTH,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.free
e, it may not be used on FreeBSD. Unless I'm
being relieved of gdb duties of course :-)
FYI,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
that perspective it's definitely valuable.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ment and maybe even
> the sparc64 requirement, but there absolutely will not be a 5.3 until
> amd64 is solid.
I think sparc64 should have KSE too. If we already accept that sparc64
is feature incomplete, we set/acknowledge a really bad precedence.
--
Marcel Moolenaar USPA: A-
us with a bit of a dilemma since David's
> work is against GDB 5.x.
And not even complete. There are still issues that haven't found a
solution or even compromise and it too is only for i386.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
_
ady stopped package builds for it
for his own sake.
Wake up, people. This is quickly becoming a joke...
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo
fail to adjust
the tierness. That's where we fail to save face.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
and 5-STABLE and no longer be a blocking item for
> releases.
Just *do* it. You've been advocating for way too long.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mon, Jun 07, 2004 at 02:32:11AM +0200, Matthias Andree wrote:
> Marcel Moolenaar <[EMAIL PROTECTED]> writes:
>
> > As for alpha, we don't even seem to be able to degrade it to tier 2
> > without losing face. kris@ has already stopped package builds for it
> &
probability should be 0. One cannot reach tier
1 from any tier >1 if binutils, gcc and gdb are not working. Hence, any
tier 2 platform must already be supported by binutils, gcc and gdb.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
modifications to binutils, so needs to be coordinated.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
#x27;t seem to get
> things working so that I have console access to the box on one serial
> port and remote gdb running on the other one. Is this possible?
Yes. Your hints are not the problem. You need to tell the kernel that
you want to use remote GDB. Boot with -g or set boot_gdb=YES in
/boot/l
buffers
when you do that...
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ine TIOCM_CAR TIOCM_DCD
#define TIOCM_RNG TIOCM_RI
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
- }
> + else if (strcmp(fstypename, "ext2fs") == 0)
> + return (LINUX_EXT2_SUPER_MAGIC);
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
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
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
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
properly when I do a make installworld?
None.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
1 - 100 of 144 matches
Mail list logo
