On 7/24/06, 李尚杰 <[EMAIL PROTECTED]> wrote:
The code for ipcperm() call :
78 ipcperm(td, perm, mode)
79 struct thread *td;
80 struct ipc_perm *perm;
81 int mode;
82 {
83 struct ucred *cred = td->td_ucred;
84 int error;
85
86 if (cred->cr_uid
On Mon, Jul 24, 2006, ?? wrote:
> 93 if (mode & IPC_M) {
> 94 error = suser(td);
> 95 if (error)
> 96 return (error);
> why not directly return the error in line 94?
Assignment could return boolean
Divacky Roman wrote:
hi,
I need to get content of %esi register as it was during a syscall. Should I get
this info from td->td_pcb->pcb_esi or td->td_frame->tf_esi?
Is it so that trapframe is "content of registers when entering a kernel" and
pcb is "when leaving a kernel" ?
pcb is when th
The code for ipcperm() call :
78 ipcperm(td, perm, mode)
79 struct thread *td;
80 struct ipc_perm *perm;
81 int mode;
82 {
83 struct ucred *cred = td->td_ucred;
84 int error;
85
86 if (cred->cr_uid != perm->cuid && cred->cr_uid != perm->uid) {
87
In message: <[EMAIL PROTECTED]>
"R. Tyler Ballance" <[EMAIL PROTECTED]> writes:
: -BEGIN PGP SIGNED MESSAGE-
: Hash: SHA1
:
: > Doesn't matter.
: >
: > I often do the following:
: >
: > setenv TARGET arm # this may be iguana for you
: > setenv TARGET_ARCH arm
2006/7/23, Divacky Roman <[EMAIL PROTECTED]>:
hi,
I need to get content of %esi register as it was during a syscall. Should I get
this info from td->td_pcb->pcb_esi or td->td_frame->tf_esi?
Is it so that trapframe is "content of registers when entering a kernel" and
pcb is "when leaving a kerne
On Sun, 23 Jul 2006, Michael Nottebrock wrote:
On Sunday, 23. July 2006 01:15, Daniel Eischen wrote:
On Sat, 22 Jul 2006, Michael Nottebrock wrote:
On Saturday, 22. July 2006 21:20, Kip Macy wrote:
I think it is because WINE stomps on or TLS. Nothing we can
do about that except patch wine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Doesn't matter.
I often do the following:
setenv TARGET arm # this may be iguana for you
setenv TARGET_ARCH arm
setenv MAKEOBJDIRPREFIX /home/imp/obj
cd p4/imp_arm
make buildworld
make buildenv # from
On 2006-07-23 15:54, Arseny Nasokin <[EMAIL PROTECTED]> wrote:
>On Sat, Jul 22, 2006 at 07:23:47AM +0300, Giorgos Keramidas wrote:
>>On 2006-07-21 17:23, Tarasov Alexey <[EMAIL PROTECTED]> wrote:
>>>Timur Yuldashev wrote:
New motd-welcome message for FreeBSD.
http://www.cwt.uz/motd
>
On Sunday, 23. July 2006 01:15, Daniel Eischen wrote:
> On Sat, 22 Jul 2006, Michael Nottebrock wrote:
> > On Saturday, 22. July 2006 21:20, Kip Macy wrote:
> I think it is because WINE stomps on or TLS. Nothing we can
> do about that except patch wine so it doesn't. Look at the
> console messag
On Sunday, 23. July 2006 00:59, Kip Macy wrote:
> Thanks. That is a useful data point but David Xu has done a lot of
> work on libthr that has probably not been MFC'd back to 5.x. When I
> get the chance I'll try building KDE on my desktop which runs a
> derivative of -CURRENT.
At least on FreeBSD
In message: <[EMAIL PROTECTED]>
"R. Tyler Ballance" <[EMAIL PROTECTED]> writes:
: -BEGIN PGP SIGNED MESSAGE-
: Hash: SHA1
:
: >>
: >> Between varying versions of userland tools (like config(8)) and path
: >> troubles, I'm wondering what tips anybody has to doing non-standard
:
On Sunday 23 July 2006 11:18, Divacky Roman wrote:
> On Sat, Jul 22, 2006 at 07:15:35PM -0400, Daniel Eischen wrote:
> > I think it is because WINE stomps on or TLS. Nothing we can
> > do about that except patch wine so it doesn't. Look at the
> > console messages for:
> >
> > Warning: pid XXX
On Sunday 23 July 2006 11:18, Divacky Roman wrote:
> On Sat, Jul 22, 2006 at 07:15:35PM -0400, Daniel Eischen wrote:
> > I think it is because WINE stomps on or TLS. Nothing we can
> > do about that except patch wine so it doesn't. Look at the
> > console messages for:
> >
> > Warning: pid XXX
On Sat, Jul 22, 2006 at 07:23:47AM +0300, Giorgos Keramidas wrote:
> On 2006-07-21 17:23, Tarasov Alexey <[EMAIL PROTECTED]> wrote:
> >Timur Yuldashev wrote:
> >> New motd-welcome message for FreeBSD.
> >>
> >> http://www.cwt.uz/motd
> >>
> >> best regards
> >
> > I like it! Very good.
>
> I do
hi,
I need to get content of %esi register as it was during a syscall. Should I get
this info from td->td_pcb->pcb_esi or td->td_frame->tf_esi?
Is it so that trapframe is "content of registers when entering a kernel" and
pcb is "when leaving a kernel" ?
thnx for info
roman
---
"R. Tyler Ballance" <[EMAIL PROTECTED]> writes:
> This doesn't solve the problem of different versions of userland
> tools required.
$ cd /foo/bar/src
$ make kernel-toolchain TARGET_ARCH=iguana
$ make buildkernel TARGET_ARCH=iguana
no need for a jail or a chroot or anything; buildkernel will use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Between varying versions of userland tools (like config(8)) and path
troubles, I'm wondering what tips anybody has to doing non-standard
builds of the kernel (non-standard being not in /usr/src and not the
host arch)
Currently the make command I'm
On 2006-07-22 20:51, "R. Tyler Ballance" <[EMAIL PROTECTED]> wrote:
> I'm just wondering, the machine-dependent assembly tied into the i386
> kernel, that's all named ${FILENAME}., while in the arm/ kernel
> machine-dependent code is named ${FILENAME}.S, what's the difference?
> Or is there none, j
On 2006-07-22 20:07, "R. Tyler Ballance" <[EMAIL PROTECTED]> wrote:
> I'm working on a project that relies on me building kernels outside
> of the standard /usr/src (typically ~/perforce/projects/ ) on my
> relatively standard 6.1-STABLE workstation. I'm wondering if I'd be
> best suited by setting
in the source code kern/sysv_shm.c:
729 error = ipcperm(td, &shmseg->u.shm_perm, mode);
730 #ifdef MAC
731 error = mac_check_sysv_shmget(td->td_ucred, shmseg, uap->shmflg);
732 if (error != 0)
733 MPRINTF(("mac_check_sysv_shmget returned %d\n", error));
734
On Sat, Jul 22, 2006 at 07:15:35PM -0400, Daniel Eischen wrote:
> On Sat, 22 Jul 2006, Michael Nottebrock wrote:
>
> >On Saturday, 22. July 2006 21:20, Kip Macy wrote:
> >>Thanks for your input.
> >>
> >>The relative merits of the different threading libraries is currently
> >>under discussion. Co
22 matches
Mail list logo