On Jun 24, 2011, at 7:11 AM, Hans Petter Selasky wrote:
> On Friday 24 June 2011 14:59:37 Robert Millan wrote:
>> 2011/6/24 Hans Petter Selasky :
Very nice. But why not use variable names instead of hardcoding
numbers? It makes the output much easier to understand.
>>>
>>> To save mem
2011/6/24 Hans Petter Selasky :
>> Very nice. But why not use variable names instead of hardcoding numbers?
>> It makes the output much easier to understand.
>
> To save memory.
I haven't inspected devd code, but I was under the assumption that
variables only lived untill resolved. What would be
On Friday 24 June 2011 14:59:37 Robert Millan wrote:
> 2011/6/24 Hans Petter Selasky :
> >> Very nice. But why not use variable names instead of hardcoding
> >> numbers? It makes the output much easier to understand.
> >
> > To save memory.
>
> I haven't inspected devd code, but I was under the
2011/6/24 Hans Petter Selasky :
> Updated bus_auto.conf:
>
> http://hselasky.homeunix.org:8192/bus_auto.conf
Very nice. But why not use variable names instead of hardcoding numbers? It
makes the output much easier to understand.
--
Robert Millan
___
2011/6/23 Warner Losh :
> How'd you go about generating all these .conf files?
I have to admit it was quite boring, lots of grep & sed, different
regex for each file, then some manual editting.
But I see that someone has found a better way. I'll look into testing that :-)
> I don't see where yo
On Friday 24 June 2011 09:22:57 Robert Millan wrote:
> 2011/6/24 Hans Petter Selasky :
> > Updated bus_auto.conf:
> >
> > http://hselasky.homeunix.org:8192/bus_auto.conf
>
> Very nice. But why not use variable names instead of hardcoding numbers?
> It makes the output much easier to understand.
On Friday 24 June 2011 04:37:25 Hans Petter Selasky wrote:
> Hi,
>
> I need some people testing the following patch:
>
> http://svn.freebsd.org/changeset/base/223486
>
> svn up and build a new kernel.
>
> Try to remove all USB devices from kernel config except the host
> controllers and USB key
Hi,
I need some people testing the following patch:
http://svn.freebsd.org/changeset/base/223486
svn up and build a new kernel.
Try to remove all USB devices from kernel config except the host controllers
and USB keyboard. Then put the following file into /etc/devd/
http://hselasky.homeunix.o
On Thursday 23 June 2011 20:37:33 Warner Losh wrote:
> How'd you go about generating all these .conf files?
>
> I don't see where you defined USB_* as variables in them either. Maybe you
> could point me at it?
>
> Warner
>
> On Jun 23, 2011, at 10:00 AM, Robert Millan wrote:
> >
Hi Warner,
How'd you go about generating all these .conf files?
I don't see where you defined USB_* as variables in them either. Maybe you
could point me at it?
Warner
On Jun 23, 2011, at 10:00 AM, Robert Millan wrote:
>
___
freebsd-hackers@freebsd.org maili
Hi Doug,
I tried using the MODULE_DEBUG #define and I ran into some compile
issues. This patch gets things to work and adds an official option /
entry to NOTES for help with other folks debugging kern_module.c
logic. I also added some additional data to assist with determining
causes of failure,
-- Forwarded message --
From: william wallace <[EMAIL PROTECTED]>
Date: Jun 7, 2006 11:13 AM
Subject: Re: misc questions about the device&driver arch
To: "M. Warner Losh" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Scott Long <[EMAIL PROTECTED]>
L PROTECTED]> writes:
: > : On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote:
: > : > From: "william wallace" <[EMAIL PROTECTED]>
: > : > Subject: Re: misc questions about the device&driver arch
: > : > Date: Sat, 20 May 2006 13:39:08 +0800
: &
osh <[EMAIL PROTECTED]> wrote:
: > From: "william wallace" <[EMAIL PROTECTED]>
: > Subject: Re: misc questions about the device&driver arch
: > Date: Sat, 20 May 2006 13:39:08 +0800
: >
: > > comparing the method array of pci_pci and cardbusbridge:
: > &
On 6/4/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
In message: <[EMAIL PROTECTED]>
: > > > Warner
: Prior to removing a card from the system, two things must occur:
:
: The device's driver must cease accessing the card.
:
: The card must cease generation transaction and interrupts.
:
: How this
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote:
: > From: "william wallace" <[EMAIL PROTECTED]>
: > Subject: Re: misc questions about the device&
On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote:
From: "william wallace" <[EMAIL PROTECTED]>
Subject: Re: misc questions about the device&driver arch
Date: Sat, 20 May 2006 13:39:08 +0800
> comparing the method array of pci_pci and cardbusbridge:
> what
On 11/6/05, John Baldwin <[EMAIL PROTECTED]> wrote:
No, FreeBSD doesn't currently do what this decribes yet. It would be
possible
to do it by adding a new device_pause() method that drivers would be
required
to implement while the resources were shuffled around though and possibly
a
device_unp
Sir :
question one :
I see lots' of use of pcib_get_bus but i cannot see the
defination ,where is it ?
question two:
what is the relationship among 1device_delete_child
2devclass_delete_device and 3devclass_delete_driver
there seems some overlap among them :)
1devclass_delete_driver ->de
Sir :
thank u for ur remind . I see the difference between GPL and
freebsd way .at present I am trying to find a way to Freebsd PCI
hotplug , and borrow some idea from linux ;after i have make sure
what to do and what's on ,i will eliminate the linux shadow and build
pure native FreeBSD ,
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: BTW :my current code is mainly translate the pcie natve hotplug from
: linux , not from the spec ,and encapsulate the BSD pci config function
: with the linux-alike interface , i wonder if i am walking the r
thank sir ,below is my opinion
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
On Tue, 30 May 2006, william wallace wrote:
> On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
>> william wallace wrote:
>
>> >>
>> > I have to clarify my intentions that i am not TRYing to do a userland
>> > PCI e
william wallace wrote:
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe cha
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe changes this from a well know
On 5/30/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: Sir：
: I have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_r
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe changes this from a well known
> constant for all pci busses, to a variable one.
In message: <[EMAIL PROTECTED]>
"william wallace" <[EMAIL PROTECTED]> writes:
: Sir：
: I have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
: f, size_t
Sir：
I have got the way to map linux pci access way to the BSD way :)
now ,several more question ,wondering :(
FIRST
struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
f, size_t size)
struct cardbus_devinfo {
struct pci_devinfo pci;
uint8_tmprefetchable;
sir , i am reading /writing directly to a pcib 's configure space
,but i found it difficult to decide which function to use and how to
get the bus ,device and function from the device structure
shall i use PCI_READ_CONFIG（bus, devlist[numdevs] ,xx, 2）
or shall i use PCIB_READ_CONFIG(device_t dev,
hi ,all
I am porting something from linux to freebsd ,i found the
DataTypes hard to translate ,then i saw that many types inlinux can be
found in drm_os_freebsd.h,such as
typedef int8_ts8;
typedef int16_t s16;
typedef int32_t s32;
typedef u_int8_t u8;
typedef u_int16_t u16;
typede
william wallace wrote this message on Wed, May 24, 2006 at 21:13 +0800:
> roger really good tips :)
> and so far as i know ,
> the PCI configure space is accessed by pci_read_config,and so on
> the PCI IO space is accessed by
bus_space_read_1 and friends...
> the PCI memory space is ac
> the PCI configure space is accessed by pci_read_config,and so on
> the PCI IO space is accessed by
> the PCI memory space is accessed by bus_space_read_1 and so on
> am i right sir?
Yes.
Warner
___
freebsd-hackers@freebsd.org mailing lis
roger really good tips :)
and so far as i know ,
the PCI configure space is accessed by pci_read_config,and so on
the PCI IO space is accessed by
the PCI memory space is accessed by bus_space_read_1 and so on
am i right sir?
On 5/24/06, John-Mark Gurney <[EMAIL PROTECTED]> wrote:
wi
william wallace wrote this message on Wed, May 24, 2006 at 15:48 +0800:
> IN static device_method_t pci_methods[] = {
> what is the freeBSD's magic to connect pci_read_config_methodwtih
> PCI_READ_CONFIG? awk script?and so on?
> which
> DEVMETHOD(pci_read_config,pci_read_config_method), in
IN static device_method_t pci_methods[] = {
what is the freeBSD's magic to connect pci_read_config_methodwtih
PCI_READ_CONFIG? awk script?and so on?
which
DEVMETHOD(pci_read_config, pci_read_config_method), in pci.c
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); in
pci_enable_io_
william wallace wrote:
[...]
MSI:
I've bantered around different suggestions for an API that will support
this. The basic thing that a driver needs from this is to know
exactly how many message interrupt vectors are available to it. It
can't just register vectors and handlers blindly since th
william wallace wrote this message on Tue, May 23, 2006 at 09:16 +0800:
> In order to keep the API as consistent as possible between classic
> interrupt sources and MSI sources, I'd like to add a new bus method:
>
> int
> bus_reserve_resource(device_t, int *start, int *end, int *count, int flags);
I just have fossicked some idea from [EMAIL PROTECTED] "PCI-Express support "
PCI-Express support
All,
I've emailed before about supporting various aspects of PCI-Express and
especially MSI, but haven't really gotten too far with it due to lack of
resources. I now how access to a system that c
> > That happens at attach time. Cardbus right now has a private protocol
> > between the card bus bridge (cbb) and the bus to know when there's a
> > new card in a slot and to enumerate that bus.
> i think that 's because in cardbus protocol ,one bus only have one
> device ,so does pci express p
On 5/22/06, Warner Losh <[EMAIL PROTECTED]> wrote:
From: "william wallace" <[EMAIL PROTECTED]>
Subject: Re: misc questions about the device&driver arch
Date: Sun, 21 May 2006 16:08:00 +0800
> On 5/21/06, Warner Losh <[EMAIL PROTECTED]> wrote:
> > nope
From: "william wallace" <[EMAIL PROTECTED]>
Subject: Re: misc questions about the device&driver arch
Date: Sun, 21 May 2006 16:08:00 +0800
> On 5/21/06, Warner Losh <[EMAIL PROTECTED]> wrote:
> > nope. It may be called once per bus instance per driver, if the b
On 5/21/06, Warner Losh <[EMAIL PROTECTED]> wrote:
nope. It may be called once per bus instance per driver, if the bus
is not self-identifying. If the bus is self-idntiying, chances are
that it will not be called. pci never calls its children drivers'
identify routine because it already knows
t; nexus_add_child),
> Nexus.c (i386\i386): DEVMETHOD(bus_add_child,nexus_add_child),
> Nexus.c (ia64\ia64): DEVMETHOD(bus_add_child,nexus_add_child),
> Ppbconf.c (dev\ppbus):DEVMETHOD(bus_add_child,
> ppbus_add_child),
> Smbus.c (dev\smbus):DEVMETHOD(bus_a
ke
ivars are setup properly by the bus for the device..
> On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote:
> >From: "william wallace" <[EMAIL PROTECTED]>
> >Subject: Re: misc questions about the device&driver arch
> >Date: Sat, 20 May 2006 13:3
bus): DEVMETHOD(bus_add_child,ppbus_add_child),
Smbus.c (dev\smbus):DEVMETHOD(bus_add_child,smbus_add_child),
On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote:
From: "william wallace" <[EMAIL PROTECTED]>
Subject: Re: misc questions about the device&driver arc
From: "william wallace" <[EMAIL PROTECTED]>
Subject: Re: misc questions about the device&driver arch
Date: Sat, 20 May 2006 13:39:08 +0800
> comparing the method array of pci_pci and cardbusbridge:
> what losts in pci bridge but exist in cardbusbridge:
> 1 card inte
> does that mean that whenever a new device or a new driver is add to
> the system ,a corresponding deviceclass will equally be created,
> am i right ,sir?
Yes. That's right.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote:
Busses create devices to represent hardware in the system. The bus
then causes these devices to be probed and attached. This latter
usage is for those cases. As drivers are loaded these devices are
offered to the new (and old) drivers in the
comparing the method array of pci_pci and cardbusbridge:
what losts in pci bridge but exist in cardbusbridge:
1 card interface
2 power interface
3 some functions :
3ain bus interface
(bus_driver_added, cbb_driver_added),
(bus_child_detached,cbb_child_detac
> about devclass_find_internal
> devclass_find_internal will be called to create a new devclass in
> such 2 conditions :
> one is creating a new device , as : if (name) { dc =
> devclass_find_internal(name, 0, TRUE);
> another is in the function:devclass_add_driver. but ,if a driver 's
> name i
about devclass_find_internal
devclass_find_internal will be called to create a new devclass in
such 2 conditions :
one is creating a new device , as : if (name) { dc =
devclass_find_internal(name, 0, TRUE);
another is in the function:devclass_add_driver. but ,if a driver 's
name is different f
In message: <[EMAIL PROTECTED]>
"Wallace William" <[EMAIL PROTECTED]> writes:
: I have seen this in the freebsd 5 road map,have the hotplug of pci already
: merged into the RELENG_5 branch?
Not as such, no. CardBus cards can be hot plugged, but no other hot
plug bridge technology has
I have seen this in the freebsd 5 road map,have the hotplug of pci already
merged into the RELENG_5 branch?
PCI resource allocation: PC2003 compliance requires that x86 systems no
longer configure PCI devices from the system BIOS, leaving this task solely
to the OS. FreeBSD must gain the ability
> We only try
> to alloc resources if the BIOS doesn't, and I'm not sure how we handle a
> bridge running out of resources. I think we might just fail the allocation.
Yes. The allocation would fail.
Warner
___
freebsd-hackers@freebsd.org mailing lis
On Thursday 10 November 2005 05:48 am, kylin wrote:
> Sir ,i am still puzzled by the windows and freebsd arch similar.
> 1
> the window TPS say that windwo allocate the resource window in default
> size of 1M or 2M,so there may be hole ,does that happen in freebsd 5
> or 6?
No.
> 2
> in my view i
Sir ,i am still puzzled by the windows and freebsd arch similar.
1
the window TPS say that windwo allocate the resource window in default
size of 1M or 2M,so there may be hole ,does that happen in freebsd 5
or 6?
2
in my view i believe that freebsd us the "just enough "tactics,so
the nexus level of
On 11/6/05, John Baldwin <[EMAIL PROTECTED]> wrote:
> On Sunday 06 November 2005 06:14 am, kylin wrote:
> > On 11/6/05, M. Warner Losh <[EMAIL PROTECTED]> wrote:
> > > In message: <[EMAIL PROTECTED]>
> > >
> > >kylin <[EMAIL PROTECTED]> writes:
> > > : ///
> > > : pci bridge
On Sunday 06 November 2005 06:14 am, kylin wrote:
> On 11/6/05, M. Warner Losh <[EMAIL PROTECTED]> wrote:
> > In message: <[EMAIL PROTECTED]>
> >
> >kylin <[EMAIL PROTECTED]> writes:
> > : ///
> > : pci bridge dynamic resize
> > : /
> > : it seems that the device
On 11/6/05, M. Warner Losh <[EMAIL PROTECTED]> wrote:
> In message: <[EMAIL PROTECTED]>
>kylin <[EMAIL PROTECTED]> writes:
> : ///
> : pci bridge dynamic resize
> : /
> : it seems that the device arch of freebsd is similar to what is revealed in
> : window OS. i
In message: <[EMAIL PROTECTED]>
kylin <[EMAIL PROTECTED]> writes:
: ///
: pci bridge dynamic resize
: /
: it seems that the device arch of freebsd is similar to what is revealed in
: window OS. i have read the pcie hotplug tps of windows longhorn ,it is said
: th
hello every one :) good day!
i have list the 3 puzzle coming to me in my recent coding reading of freebsd
0
///
pci bridge dynamic resize
/
it seems that the device arch of freebsd is similar to what is revealed in
window OS. i have read the pcie hotplug tps of windows longh
On 23-Mar-2003 [EMAIL PROTECTED] wrote:
>
>> Using kbdcontrol -b off on my laptop running current does
>> turn off the sound already.
>
> I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it
> still did not turn off the beeper. I have also checked
> 'syscons.c', v. 1.399 ([0]), and foud o
> Using kbdcontrol -b off on my laptop running current does
> turn off the sound already.
I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it
still did not turn off the beeper. I have also checked
'syscons.c', v. 1.399 ([0]), and foud only one change
concerning keybell:
'if (cold || shutd
> Incidentally, using quiet.off doesn't
> shut it up either which is very confusing since quiet sets
> SC_QUIET_BELL.
it does, actually
the `man kbdcontrol` doesn't say that it also checks to see
if the beeping console is not current:
if (scp != scp->sc->cur_scp && (scp->sc->flags & SC_QUIET_BELL
On 22-Mar-2003 [EMAIL PROTECTED] wrote:
>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=41772
> This appears to be _VERY_ old problem (I don't remember
> it on 2.2.7-RELEASE, though)
> In short: the beeper still produces noises (clicks) when
> shut up with `kbdcontrol -b off`
Using kbdcontrol -b
> http://www.freebsd.org/cgi/query-pr.cgi?pr=41772
This appears to be _VERY_ old problem (I don't remember
it on 2.2.7-RELEASE, though)
In short: the beeper still produces noises (clicks) when
shut up with `kbdcontrol -b off`
Finally I got some time to look at
'sys/dev/syscons/syscons.c'. However
In browsing through the old, open, PRs I found misc/18466 (from May,
2000). It's got the potential to be a source of substantial confusion, so
it seems to be worth addressing.
The fix seems trivial, and I've attached a very simple patch to
sysinstall.h that should fix the problem. I&#x
Hello,
I had submitted misc/42422 and misc/42429 over 5 months ago and am
going to try one more time to get them applied.
misc/42422 is a simple 4 line patch to lib/libc/db/ndbm.c and misc/42429
is a 3 line patch to src/lib/libc/db/hash.c.
They both concern how the return values are in
Patrick Thomas <[EMAIL PROTECTED]> writes:
> > No, procfs is pretty much useless these days (except for truss).
> In 4.5, won't `ps` (and perhaps other apps) not work for people in a jail
> if their jail does not have a proc file system mounted in their /proc ?
Only 'ps -e'. Everything else will
> Patrick Thomas <[EMAIL PROTECTED]> writes:
> > 1. Does each jail need to have its own proc filesystem mounted?
>
> No, procfs is pretty much useless these days (except for truss).
In 4.5, won't `ps` (and perhaps other apps) not work for people in a jail
if their jail does not have a proc file
Patrick Thomas <[EMAIL PROTECTED]> writes:
> 1. Does each jail need to have its own proc filesystem mounted?
No, procfs is pretty much useless these days (except for truss).
> 2. Does kern.maxproc scale in a linear fashion with maxusers ?
The default value for kern.maxproc is 20 + 16 * maxusers
Patrick Thomas wrote:
> 1. Does each jail need to have its own proc filesystem mounted?
It depends on how you plan to use it. If you use no programs
that need procfs, then you don't need it.
> The
> original jail documentation says to do that, but I have heard rumors that
> this is not necessar
1. Does each jail need to have its own proc filesystem mounted ? The
original jail documentation says to do that, but I have heard rumors that
this is not necessary. What is the negative ramifications (if any) to
running a jail without its own seperately mounted proc filesystem ? (I
have a tes
Bela Bartok wrote:
>
> hi, i am student of computer science, hooked on 2 oses: solaris
> and freebsd. I want to understand why people say: 'binaries are not
> loaded on memory they are mapped (man 2 mmap)' ?.
Because they are demand paged. The pages in a 1M binary are
only loaded as they are re
hi, i am student of computer science, hooked on 2
oses: solaris and freebsd. I w
ant to understand why people say: 'binaries are not
loaded on memory they are ma
pped (man 2 mmap)' ?.
Also, Can any of you explain me in another way (like
graphical or easy-to-learn)
way in which i can understand th
> On Sun, Oct 28, 2001 at 08:10:25PM -0800, Igor M Podlesny wrote:
hm.. it seems somebody has multiplied my timezone by -1 ;-)
>>
>> You might observe this bug doing traceroute while standing behind
>> a GW's interface with several IP-addresses (aliases). In this case
>> you always got ICMP.TIM
folks,
I know it's the eleventh hour, but can we get this trivial but
annoying bug fixed for 4.3? I get tired of rebooting my laptop after a
buildworld and having it not set the hostname.
Adrian
--
[ [EMAIL PROTECTED] ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
> If it is for a compile-time check, there's a __FreeBSD_version define in
> (the kern.osreldate sysctl returns exactly this). If it is
> a configure- or run-time thing, use the sysctl as Maxime suggested.
No, it is runtime detection, and maybe it needs to be a very early
one, therefore I requ
On Thu, Sep 28, 2000 at 03:38:15PM +0200, Maxime Henrion wrote:
> Marco van de Voort wrote:
>
> > (for the development of the Free Pascal compiler port):
> >
> > - Is there a way to easily check FreeBSD version (3.x or 4.x+, because of
> > the different syscallnrs for signal functions) on syscall
Marco van de Voort wrote:
> (for the development of the Free Pascal compiler port):
>
> - Is there a way to easily check FreeBSD version (3.x or 4.x+, because of
> the different syscallnrs for signal functions) on syscall level?
>
Use the sysctl kern.osreldate.
>
> - Can I use the assembler ins
(for the development of the Free Pascal compiler port):
- Is there a way to easily check FreeBSD version (3.x or 4.x+, because of
the different syscallnrs for signal functions) on syscall level?
- Can I use the assembler instruction ENTER ? E.g. Linux doesn't allow it,
because it would
t has the internal identification `misc/12633'.
The individual assigned to look at your
report is: freebsd-bugs.
>Category: misc
>Responsible:freebsd-bugs
>Synopsis: CMI8330 chip based integrated sound card produce no output
>Arrival-Date: Tue Ju
t has the internal identification `misc/12633'.
The individual assigned to look at your
report is: freebsd-bugs.
>Category: misc
>Responsible:freebsd-bugs
>Synopsis: CMI8330 chip based integrated sound card produce no output
>Arrival-Date: Tue Ju
Does anyone feel strongly about the small patch in misc/3237 to add support
for handling installation of script files in bsd.prog.mk?
I can certainly see how this could be useful.
Kris
-
"Never criticize anybody until you have walked a mile in their shoes,
because by that time you will
Does anyone feel strongly about the small patch in misc/3237 to add support
for handling installation of script files in bsd.prog.mk?
I can certainly see how this could be useful.
Kris
-
"Never criticize anybody until you have walked a mile in their shoes,
because by that time you wi
Alex Charalabidis <[EMAIL PROTECTED]> writes:
> On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> > The PR is wrong. Sheldon is right. It *does* work the way it ships. If
> > he experienced problems, I bet the real bug was that he edited
> > inetd.conf, HUPed inetd, and hit the "HUP clobbers the servic
Alex Charalabidis writes:
> On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> > The PR is wrong. Sheldon is right. It *does* work the way it ships. If
> > he experienced problems, I bet the real bug was that he edited
> > inetd.conf, HUPed inetd, and hit the "HUP clobbers the service table"
> > bug.
>
On Mon, 21 Jun 1999 12:10:47 MST, Doug wrote:
> In fact, the man page is correct, however the inetd code currently
> has an outdated version of the canonical name. Thus, at minimum the
> man page should be udpated to reflect this reality. A better solution
> would be to remove the hard coded va
On Mon, 21 Jun 1999 12:10:47 MST, Doug wrote:
> In fact, the man page is correct, however the inetd code currently
> has an outdated version of the canonical name. Thus, at minimum the
> man page should be udpated to reflect this reality. A better solution
> would be to remove the hard coded val
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> Doug <[EMAIL PROTECTED]> writes:
> > "It doesn't work with the conf file that came with the system, but
> > it does work if I change the conf file to match the documentation" is
> > pretty good content in my book. Obviously he doesn't include infor
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> Doug writes:
> > "It doesn't work with the conf file that came with the system, but
> > it does work if I change the conf file to match the documentation" is
> > pretty good content in my book. Obviously he doesn't include information
> > on how to
Doug <[EMAIL PROTECTED]> writes:
> "It doesn't work with the conf file that came with the system, but
> it does work if I change the conf file to match the documentation" is
> pretty good content in my book. Obviously he doesn't include information
> on how to repeat the problem in a verifia
Doug writes:
> "It doesn't work with the conf file that came with the system, but
> it does work if I change the conf file to match the documentation" is
> pretty good content in my book. Obviously he doesn't include information
> on how to repeat the problem in a verifiable way, but that do
On Mon, 21 Jun 1999, Sheldon Hearn wrote:
>
>
> On Mon, 21 Jun 1999 11:42:46 MST, Doug wrote:
>
> > [...] there is an outstanding PR that shows it
> > doesn't work for everybody, and there is absolutely no justification for
> > leaving an example in the conf file that conflicts with the man pa
By the way, I'd recommend all -CURRENT users, after making world, make a
new copy of pidentd. The code to grovel through the kernel to find socket
info is MUCH less sickening now, so identd is less of a performance hit
and less likely to fail due to race conditions.
Brian Fundakowski Feldman
On Mon, 21 Jun 1999, Sheldon Hearn wrote:
>
>
> On Mon, 21 Jun 1999 11:42:46 MST, Doug wrote:
>
> > [...] there is an outstanding PR that shows it
> > doesn't work for everybody, and there is absolutely no justification for
> > leaving an example in the conf file that conflicts with the man pag
By the way, I'd recommend all -CURRENT users, after making world, make a
new copy of pidentd. The code to grovel through the kernel to find socket
info is MUCH less sickening now, so identd is less of a performance hit
and less likely to fail due to race conditions.
Brian Fundakowski Feldman
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> Doug <[EMAIL PROTECTED]> writes:
> > You are really really missing my point here, so I will state it
> > again. If you have carefully examined the code for *every* case of *every*
> > internal service, and you have tested it thoroughly, and you are
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> Doug writes:
> > You are really really missing my point here, so I will state it
> > again. If you have carefully examined the code for *every* case of *every*
> > internal service, and you have tested it thoroughly, and you are 100% sure
> > that
On Mon, 21 Jun 1999 11:42:46 MST, Doug wrote:
> [...] there is an outstanding PR that shows it
> doesn't work for everybody, and there is absolutely no justification for
> leaving an example in the conf file that conflicts with the man page.
Doug, I'm annoyed that you ignored the most importan
1 - 100 of 114 matches
Mail list logo
