On Mon, Nov 15, 2010 at 9:53 AM, Garrett Cooper wrote:
> According to SYSCTL_INT(9):
>
> The SYSCTL kernel interfaces allow code to statically declare sysctl(8)
> MIB entries, which will be initialized when the kernel module containing
> the declaration is initialized. When the mod
(Taking to -hackers by request)
My old (Ubuntu) laptop died and I have replaced it with a Macbook Air.
I know from visual inspection at BSDCan that 50% of the attending
developers own a Mac laptop of some kind.
However, I've been a bit stumped on how to share the source code from
my Mac with the
g on various ports.
Even with the firewall off I get the same "Client credential too weak"
error. I get the same error when I change /etc/exports on the Mac and
/etc/fstab on the FreeBSD VM to /Users/mdf.
So... I'm pretty stumped.
Thanks,
matthew
___
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"
r/log;
> a grep for mountd in /var/log/*.log only has hits in
> launchd-shutdown.log. A grep for nfsd in /var/log/*.log doesn't
> *seem* to have anything useful, just a few in appfirewall.log about
> nfsd listening on various ports.
>
> Even with the firewall off I get the same "
There are very few uses in FreeBSD mainline code of
sysctl_remove_oid(), and I was looking at potentially removing them.
However, the use in coretemp/amdtemp has me slightly stumped.
Each device provides a device_get_sysctl_ctx sysctl_ctx that is
automatically cleaned up when the device goes away.
I thought I knew something about how the compiler looks for include
files, but now I think maybe I don't know much. :-)
So here's what I'm pondering. When I build a library, like e.g. libc,
where do the include files get pulled from? They can't (shouldn't) be
the ones in /usr/include, but I don'
ARWIN ones fcntl(F_RDADVISE)?
>>
>> It is like madvise(2) but for file descriptors.
> No, it does not (and I think the function is spelled posix_fadvise()).
>
> mdf reserved the syscall slot for posix_fadvise in his recent work
> on posix_fallocate(). Might be, he could comme
2011/5/12 Lev Serebryakov :
> Hello, Mdf.
> You wrote 12 мая 2011 г., 15:40:25:
>
>>>> Does FreeBSD have some custom call, which can be used where Linux
>>>> programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)?
>>>>
>>>> I
I am looking into potentially MFC'ing r212367 and related, that adds
drains to sbufs. The reason for MFC is that several pieces of new
code in CURRENT are using the drain functionality and it would make
MFCing those changes much easier.
The problem is that r212367 added a pointer to a drain funct
On Sun, Jun 5, 2011 at 11:13 AM, Ben Laurie wrote:
> So, for example int64_t has no printf modifier I am aware of. Likewise
> its many friends.
The worse option is to use the C99 defines, like PRI64 and PRI64U.
The better option is to use %jd / %ju and cast the value to
[u]intmax_t.
Cheers,
matt
There is a check in the function implementing readdir(3) for a zero
inode number:
struct dirent *
_readdir_unlocked(dirp, skip)
DIR *dirp;
int skip;
{
/* ... */
if (dp->d_ino == 0 && skip)
continue;
/* ... */
}
"skip" is 1 ex
On Fri, Jun 24, 2011 at 6:14 AM, John Baldwin wrote:
> On Friday, June 24, 2011 3:23:11 am Sebastian Huber wrote:
>> Hello,
>>
>> exists there some unit tests for FreeBSD kernel APIs, e.g. mutex(9),
>> condvar(9), etc.?
>>
>> Have a nice day!
>
> Hmm, I have a kernel module that does some tests, b
On Tue, Jul 5, 2011 at 6:36 AM, Robert Millan wrote:
> 2011/7/5 Dimitry Andric :
>> As far as I can see, this code only gives warnings when compiled with
>> gcc 4.5 or higher, and when using the -Wundef flag. Isn't it easier to
>> just remove the -Wundef flag here?
>
> Here's a patch to remove -W
On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote:
> Please consider this patch - it unifies sysctls: vm.kvm_size and
> vm.kvm_free.
>
> Currently these sysctls are only found under i386 and amd64:
>
> sys/i386/i386/pmap.c
> sys/i386/xen/pmap.c
> sys/amd64/amd64/pmap.c
>
> It seems logical (to
On Mon, Jul 18, 2011 at 7:47 AM, Uffe Jakobsen wrote:
> On 2011-07-18 15:54, m...@freebsd.org wrote:
>> On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote:
>>>
>>> Please consider this patch - it unifies sysctls: vm.kvm_size and
>>> vm.kvm_free.
>>>
>>> Currently these sysctls are only found un
On Mon, Aug 29, 2011 at 7:46 AM, Ivan Voras wrote:
> On 26/08/2011 19:44, Garrett Cooper wrote:
>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>
>> ...
>>
>>> I think that I'll need a 9-CURRENT snapshot on it to run all 128 CPUs,
>>> right?
>>
>> A 9.0-BETA1 snapshot, yes.
>
> Well, I'll
On Wed, Sep 7, 2011 at 11:08 AM, Charlie Martin wrote:
> I'm still pursuing a FreeBSD bug in "7.2-PRERELEASE FreeBSD" -- and yes, we
> know this is wildly out of date, but it's not feasible to upgrade right now
> -- and while trying to backport a fix suggested here
> http://permalink.gmane.org/gma
On Wed, Sep 7, 2011 at 12:24 PM, Charlie Martin wrote:
>
>
> On 2011-09-07 12:53, m...@freebsd.org wrote:
>>>
>>> For my immediate purposes, I'd be happy with any way in which I could
>>> > brutally kill the kernel and force it to the debugger, say by
>>> > replacing the
>>> > panic call with a
2011/10/2 Lev Serebryakov :
> Hello, Freebsd-hackers.
>
> Here are several memory-allocation mechanisms in the kernel. The two
> I'm aware of is MALLOC_DEFINE()/malloc()/free() and uma_* (zone(9)).
>
> As far as I understand, malloc() is general-purpose, but it has
> fixed "transaction cost" (in
2011/10/2 Lev Serebryakov :
> Hello, Freebsd-hackers.
>
> What should I use to measure short intervals of time between events
> in kernel? I don't need any "time" in means of, for example, time(3)
> API, but some monotonically and uniformly increasing counter with
> known frequency. As cheap as po
2011/10/3 Lev Serebryakov :
> Is here atomic increment and get (or add and get) operation in
> kernel? I cannot find one. Here is atomic_add_32(), but it doesn't
> return result. And here is no atomic_add_64() on 32 bit system :(
See atomic_fetchadd_int.
Not all hardware has 64-bit atomic inst
On Mon, Oct 3, 2011 at 7:55 AM, satish kondapalli wrote:
> I am new to FreeBSD, I just want know whether FreeBSD supports NUMA.
> If FreeBSD supports NUMA what are the kernel API to allocate memory?
> is there any example driver or any driver which is using the NUMA API?
>
> please provide some in
On Mon, Oct 3, 2011 at 10:24 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Oct 3, 2011 at 12:31 PM, wrote:
>> On Mon, Oct 3, 2011 at 7:55 AM, satish kondapalli
>> wrote:
>>> I am new to FreeBSD, I just want know whether FreeBSD supports NUMA.
>>> If FreeBSD supports NUMA what are the kernel API
2011/10/7 Mustafa Reşit Şahin :
> I am trying to run Valgrind on FreeBSD. I am getting the error about
> ksem_open which i stated below. I have searched for a solution to be able
> to solve this problem and found the calgrind patch. I could not found the
> instructions to apply this patch. How can
2011/10/30 Lev Serebryakov :
> Hello, Hackers.
>
> (SORRY FOR SENDING INCOMPLETE MESSAGE)
>
> How to express inter-directory dependencies in infrastructure?
>
> I have project, which has two subdirectories: "lib" and "bin".
> Top-level Makefile is simple one, looks like this:
>
> =
2011/10/30 Lev Serebryakov :
> Hello, Hackers.
>
> I need to pass "volatile void *" to API function, which takes
> "void*". gcc (on FreeBSD 8.2) emits warning, and as in FreeBSD-styed
> code warnings are treated as errors, program could not be built.
>
> Manual casting gives warning, too...
See
On Wed, Nov 2, 2011 at 4:56 PM, Alexander Best wrote:
> i sent the following message to freebsd-quaestions@ and got no answer. mybe it
> is better suited for freebsd-hackers@.
>
> hi there,
>
> i found hundreds of the following cases in the FreeBSD src:
>
> [...]
> struct periph_driver {
>
On Tue, Nov 15, 2011 at 12:18 PM, Maxim Ignatenko wrote:
> frHi,
>
> I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and
> looking for most convenient way to establish communication between userspace
> processes and kernel part. Communication pattern best fits to listening
>
On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou wrote:
> Hi,
>
> I was lucky to write a bit of code which gcc 4.2 fails to compile
> correctly with -O2. Too keep long story short the code fails for gcc
> from base system and last gcc 4.2 snapshot from ports. It works with gcc
> 4.3, gcc 4.4 on FreeB
On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou wrote:
> On (19/11/2011 07:26), m...@freebsd.org wrote:
>> On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou wrote:
>> > Hi,
>> >
>> > I was lucky to write a bit of code which gcc 4.2 fails to compile
>> > correctly with -O2. Too keep long story short the
On Sun, Nov 20, 2011 at 10:24 AM, Gleb Kurtsou wrote:
> On (19/11/2011 09:11), m...@freebsd.org wrote:
>> On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou wrote:
>> > On (19/11/2011 07:26), m...@freebsd.org wrote:
>> >> On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou
>> >> wrote:
>> >> > Hi,
>> >> >
On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote:
>
> Does the following change do what I think that it does?
> Thank you!
>
> Author: Andriy Gapon
> Date: Thu Sep 1 16:50:13 2011 +0300
>
> ukbd: drop local duplicate of kern_yield and use that instead
>
> diff --git a/sys/dev/usb/input/uk
On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote:
> on 11/12/2011 23:48 m...@freebsd.org said the following:
>> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote:
>>>
>>> Does the following change do what I think that it does?
>>> Thank you!
>>>
>>> Author: Andriy Gapon
>>> Date: Thu Sep
On Mon, Dec 12, 2011 at 11:05 AM, John Baldwin wrote:
> On Monday, December 12, 2011 10:58:22 am Hans Petter Selasky wrote:
>> On Monday 12 December 2011 16:55:38 m...@freebsd.org wrote:
>> > On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote:
>> > > on 11/12/2011 23:48 m...@freebsd.org said th
2011/12/18 Fernando Apesteguía :
> El 18/12/2011 22:12, "Julian Elischer" escribió:
>>
>> On 12/18/11 12:18 PM, Fernando Apesteguía wrote:
>>>
>>> Hi all,
>>>
>>> I'm writing a small module just for fun. I would like to have two
> variables:
>>>
>>> - "pid" of type unsigned int and RW so the user
On Tue, Dec 27, 2011 at 8:05 AM, Attilio Rao wrote:
> 2011/12/27 Giovanni Trematerra :
>> On Mon, Dec 26, 2011 at 9:24 PM, Venkatesh Srinivas
>> wrote:
>>> Hi!
>>>
>>> I've been playing with two things in DragonFly that might be of interest
>>> here.
>>>
>>> Thing #1 :=
>>>
>>> First, per-mountpo
On Tue, Dec 27, 2011 at 9:05 AM, Attilio Rao wrote:
> 2011/12/27 :
>> On Tue, Dec 27, 2011 at 8:05 AM, Attilio Rao wrote:
>>> 2011/12/27 Giovanni Trematerra :
On Mon, Dec 26, 2011 at 9:24 PM, Venkatesh Srinivas
wrote:
> Hi!
>
> I've been playing with two things in DragonFl
On Wed, Feb 8, 2012 at 10:33 PM, John Kozubik wrote:
> If it were up to me, I think I would stake out a very loud and clear mission
> statement for FreeBSD that explicitly sacrifices new features for longer
> lifecycles and deeper investment in particular releases. I've thought
> seriously about
On Tue, Feb 14, 2012 at 8:57 AM, Julian Elischer wrote:
> On 2/14/12 6:23 AM, Maninya M wrote:
>>
>> For multicore desktop computers, suppose one of the cores fails, the
>> FreeBSD OS crashes. My question is about how I can make the OS tolerate
>> this hardware fault.
>> The strategy is to checkpo
On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote:
> On Tue, 26 Jun 2012, Chris Rees wrote:
>
>>> as well as we don't depend of /proc for normal operation we shouldn't for
>>
>> say /proc/sysctl
>>>
>>>
>>> improvements are welcome, better documentation is welcome, changes to
>>
>> what is OK -
On Mon, Aug 13, 2012 at 1:24 AM, Hooman Fazaeli wrote:
> Hi hackers
>
> In the process of back porting drivers to older freebsd versions,
> We sometimes need to add suitable '#if __FreeBSD_version >= x ... else
> ... '
> directives to the source to use an alternate function or exclude certain
On Mon, Sep 3, 2012 at 7:29 AM, Eitan Adler wrote:
> On 3 September 2012 10:19, Ryan Stone wrote:
>> On Sun, Sep 2, 2012 at 5:45 PM, Eitan Adler wrote:
>>> Why isn't git.freebsd.org a straight "git svn clone" ? AFAIK that isn't
>>> broken.
>>
>> Well, let's put it this way: I started a git svn
On Fri, Sep 14, 2012 at 4:45 AM, Erik Cederstrand wrote:
> Den 14/09/2012 kl. 13.03 skrev Ivan Voras :
>
>> On 14/09/2012 09:49, Erik Cederstrand wrote:
>>> Hello hackers,
>>>
>>> I'm looking through the Clang Analyzer scans on
>>> http://scan.freebsd.your.org/freebsd-head looking for false posit
On Wed, Oct 17, 2012 at 4:20 AM, Andriy Gapon wrote:
>
> _mtx_lock_spin has the following check in its retry loop:
> if (i < 6000 || kdb_active || panicstr != NULL)
> DELAY(1);
> else
> _mtx_lock_spin_failed(m);
>
[snip analysis]
>
> So I'd like to propose to remove those check
On Fri, Jan 18, 2013 at 7:29 AM, Andre Oppermann wrote:
> The (inital?) size of the kmem_map is determined by some voodoo magic,
> a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables.
> However it seems to work out to an effective kmem_map_size of about 58MB
> on my 16GB AMD64 d
On Sun, Jan 20, 2013 at 3:01 PM, Yuri wrote:
> I am implementing an ioctl that reads/writes variable size structure.
> Allocated size is supplied by the caller in the structure itself.
> struct my_struct {
> int len; // allocated size
> other_struct s[1];
> };
> ioctl request id is defined as
On Sun, Jan 20, 2013 at 6:50 PM, Yuri wrote:
> On 01/20/2013 16:59, m...@freebsd.org wrote:
>
> To do what you want it sounds like you want your handler to take something
> like:
>
> struct var_ioctl {
> int len;
> void *data;
> };
>
> Then then handler itself would have to use copyin/copy
On Tue, Feb 5, 2013 at 7:14 AM, Konstantin Belousov wrote:
> On Mon, Feb 04, 2013 at 03:05:15PM -0800, Neel Natu wrote:
>> Hi,
>>
>> I have a patch to dynamically calculate NKPT for amd64 kernels. This
>> should fix the various issues that people pointed out in the email
>> thread.
>>
>> Please re
On Tue, Feb 19, 2013 at 5:11 AM, Borja Marcos wrote:
>
> Hello,
>
> I'm really sorry if this is a stupid question, but as far as I know,
> u_int64_t defined in /usr/include/sys/types.h should *always* be
> a 64 bit unsigned integer, right?
>
> Seems there's a bug (or I need more and stronger coff
extattr_list return ssize_t, so this is inconsistent.
The patch at
http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix-rmextattr-8-.patchfixes
this. It compiles but it's untested.
I don't think any compat shims are needed, since an old application will
still sign exten
t the number of bytes written, like write(2). This is
> > because extattr_set_* is declared as returning an int, not an ssize_t.
> > Both extattr_get and extattr_list return ssize_t, so this is
> inconsistent.
> >
> > The patch at
> >
> http://people.free
so this is
>> inconsistent.
>> >
>> > The patch at
>> >
>> http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix-
>> rmextattr-8-.patchfixes<http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix-rmextattr-8-.patchfixe
On Sat, Jun 8, 2013 at 3:52 PM, Dirk Engling wrote:
> The arbitrary value
>
> #define MNAMELEN88 /* size of on/from name bufs */
>
> struct statfs {
> [...]
> charf_mntfromname[MNAMELEN];/* mounted filesystem */
> charf_mntonname[MNAMELEN]; /* directo
On Fri, Jun 28, 2013 at 8:56 AM, Adrian Chadd wrote:
> On 28 June 2013 08:37, Alexander Motin wrote:
> >> Otherwise it may just creep up again after someone does another change
> >> in an unrelated part of the kernel.
> >
> > Big win or small, TAILQ is still heavier then STAILQ, while it is not
On Mon, Jul 1, 2013 at 5:42 PM, David Sanford
wrote:
> Hi,
>
> Thanks for your responses to my first question. They were very helpful.
>
> In looking at the code, I ran across the functions setprogname and
> getprogname. According to the man page:
> In FreeBSD, the name of the program is set by th
On Wed, Jun 23, 2010 at 9:03 AM, wrote:
> I've escaped to loader prompt:
> Current device is disk0s3a, from which this loader is running.
>
> My USB stick is device1 and device1s2a is UFS /, on which I would like to
> reach some file or simply list directory.
IIRC, there is no way to do this (bu
On Sun, Jul 11, 2010 at 7:58 AM, Gabor Kovesdan wrote:
> Em 2010.07.11. 16:54, Dimitry Andric escreveu:
>>
>> On 2010-07-11 16:46, Gabor Kovesdan wrote:
>>
>>>
>>> I have two int64_t variables in kernel code, first is stored internally
>>> and the second one is passed from a syscall argument. When
We've seen a few instances at work where witness_warn() in ast()
indicates the sched lock is still held, but the place it claims it was
held by is in fact sometimes not possible to keep the lock, like:
thread_lock(td);
td->td_flags &= ~TDF_SELECT;
thread_unlock(td);
What I
On Thu, Jul 29, 2010 at 4:39 PM, wrote:
> We've seen a few instances at work where witness_warn() in ast()
> indicates the sched lock is still held, but the place it claims it was
> held by is in fact sometimes not possible to keep the lock, like:
>
> thread_lock(td);
> td->td_flags
2010/7/30 Kostik Belousov :
> On Thu, Jul 29, 2010 at 04:57:25PM -0700, m...@freebsd.org wrote:
>> On Thu, Jul 29, 2010 at 4:39 PM, wrote:
>> > We've seen a few instances at work where witness_warn() in ast()
>> > indicates the sched lock is still held, but the place it claims it was
>> > held by
On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wrote:
> On Friday, July 30, 2010 10:08:22 am John Baldwin wrote:
>> On Thursday, July 29, 2010 7:39:02 pm m...@freebsd.org wrote:
>> > We've seen a few instances at work where witness_warn() in ast()
>> > indicates the sched lock is still held, but th
On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote:
> On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
>> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wrote:
>> > On Friday, July 30, 2010 10:08:22 am John Baldwin wrote:
>> >> On Thursday, July 29, 2010 7:39:02 pm m...@freebsd.org w
On Wed, Aug 4, 2010 at 11:55 AM, John Baldwin wrote:
> On Wednesday, August 04, 2010 12:20:31 pm m...@freebsd.org wrote:
>> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote:
>> > On Tuesday, August 03, 2010 9:46:16 pm m...@freebsd.org wrote:
>> >> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin
On Wed, Aug 4, 2010 at 9:20 AM, wrote:
> On Wed, Aug 4, 2010 at 2:26 PM, John Baldwin wrote:
>> Actually, I would beg to differ in that case. If PCPU_GET(spinlocks)
>> returns non-NULL, then it means that you hold a spin lock,
>
> ll_count is 0 for the "correct" pc_spinlocks and non-zero for th
>> (gdb) p panic_cpu
>> $9 = 2
>> (gdb) p dumptid
>> $12 = 100751
>> (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_curthread->td_tid
>> $14 = 100751
>>
>> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next
>> $6 = {
>> pc_curthread = 0xff00716d6960,
>> pc_cpuid = 2,
>> pc_spinlocks = 0xff
On Sun, Aug 8, 2010 at 2:43 PM, Attilio Rao wrote:
> 2010/8/4 :
>> On Fri, Jul 30, 2010 at 2:31 PM, John Baldwin wrote:
>>> On Friday, July 30, 2010 10:08:22 am John Baldwin wrote:
On Thursday, July 29, 2010 7:39:02 pm m...@freebsd.org wrote:
> We've seen a few instances at work where
On Mon, Sep 6, 2010 at 1:38 AM, Nathan Whitehorn wrote:
> PowerPC hypervisors typically provided a restricted range on memory when
> the MMU is disabled, as it is when initially handling exceptions. In
> order to restore virtual memory, the powerpc64 code needs to read a data
> structure called th
On Mon, Sep 6, 2010 at 4:28 AM, Nathan Whitehorn wrote:
> On 09/05/10 22:51, m...@freebsd.org wrote:
>> On Mon, Sep 6, 2010 at 1:38 AM, Nathan Whitehorn
>> wrote:
>>
>>> PowerPC hypervisors typically provided a restricted range on memory when
>>> the MMU is disabled, as it is when initially hand
68 matches
Mail list logo
