Nabble - freebsd-hackers

zero size set_pcpu linker sets

2009-11-24T10:29:38Z

objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu"
section of size 0. Why? What is the difference between having a 0
sized set_pcpu vs. not having it at all?

The kernel linker considers the alignment requirements of these empty
sections and advances mapsize/mapbase. This bothers my kgdb (which is
slightly modified to deal with amd64 KLDs).

I'm using the patch shown here as a stopgap measure. I think the correct
fix is to not have these empty sections in the KLD to begin with.

Regards,
Navdeep

diff -r 09b877bb00f2 sys/kern/link_elf_obj.c
--- a/sys/kern/link_elf_obj.c Mon Nov 23 12:42:09 2009 -0800
+++ b/sys/kern/link_elf_obj.c Tue Nov 24 10:13:02 2009 -0800
@@ -680,10 +680,12 @@
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
- alignmask = shdr[i].sh_addralign - 1;
- mapsize += alignmask;
- mapsize &= ~alignmask;
- mapsize += shdr[i].sh_size;
+ if (shdr[i].sh_size) {
+ alignmask = shdr[i].sh_addralign - 1;
+ mapsize += alignmask;
+ mapsize &= ~alignmask;
+ mapsize += shdr[i].sh_size;
+ }
break;
}
}
@@ -740,9 +742,15 @@
switch (shdr[i].sh_type) {
case SHT_PROGBITS:
case SHT_NOBITS:
- alignmask = shdr[i].sh_addralign - 1;
- mapbase += alignmask;
- mapbase &= ~alignmask;
+ if (shdr[i].sh_size) {
+ alignmask = shdr[i].sh_addralign - 1;
+ mapbase += alignmask;
+ mapbase &= ~alignmask;
+ }
if (ef->shstrtab && shdr[i].sh_name != 0)
ef->progtab[pb].name =
ef->shstrtab + shdr[i].sh_name;
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

IPTPS '10 CFP

2009-11-24T10:03:55Z

On behalf of the 9th International Workshop on Peer-to-Peer Systems
(IPTPS '10) program committee, we are inviting you to submit engaging
position papers on the current and future trends in peer-to-peer
systems.

Co-located with NSDI '10 in San Jose, CA, this one-day workshop provides
a venue in which to present and discuss peer-to-peer technologies,
applications, and systems and to identify key research issues and
challenges that lie ahead.

This year, the workshop's charter will be expanded to include topics
relating to self-organizing and self-managing distributed systems. This
is in response to recent trends where self-organizing techniques
proposed in early peer-to-peer systems have found their way into more
managed settings such as datacenters, enterprises, and ISPs to help deal
with growing scale, complexity, and heterogeneity. In the context of
this year's workshop, peer-to-peer systems are defined to be large-scale
distributed systems that are mostly decentralized, are self-organizing,
and might or might not include resources from multiple administrative
domains.

Papers will be selected based on originality, likelihood of spawning
insightful discussion, and technical merit. The program will include
presentations of position papers along with plenty of time for lively
discussion among the participants, as well as a demo session for working
systems.

Topics of interest include but are not limited to:

* Network and system support for peer-to-peer systems
* Self-organizing and self-managing distributed systems
* Adaptive algorithms and architectures for large-scale distributed
systems
* New applications and protocols for peer-to-peer systems
* Availability, robustness, performance, and scaling
* Security, privacy, anonymity, anti-censorship, and incentives
* Lessons drawn from experience with deployed peer-to-peer systems
* Measurement, modeling, and workload characterization

Complete paper submissions are due Friday, December 18, 2009, 11:59
p.m. EST.

For more details on the submission process, please see the complete
Call for Papers at:
http://www.usenix.org/iptps10/cfpa/

We look forward to receiving your submissions!

Michael J. Freedman, Princeton University
Arvind Krishnamurthy, University of Washington
IPTPS '10 Program Co-Chairs
iptps10chairs@...

---------------------------------
Call for Papers
9th International Workshop on Peer-to-Peer Systems (IPTPS '10)
April 27, 2010
San Jose, CA
http://www.usenix.org/iptps10/cfpa/
Submissions Deadline: December 18, 2009, 11:59 p.m. EST
---------------------------------
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

RE: Cisco Aironet MPI350 Fix

2009-11-22T23:45:47Z

ignore that, I just discovered watson.org.., sorry.

computers are not for me, really :/

Felipe.

From: gatinhodosseussonhos@...
To: obrien654j@...; freebsd-hackers@...
Subject: RE: Cisco Aironet MPI350 Fix
Date: Mon, 23 Nov 2009 05:17:30 +0100

Mr O'Brien,

I gave up of 8.0-RC3 a few days ago because I was unable of fix a missing /dev/agp,
but I got better after reading "freeze up a few seconds about once a minute",
just after restart a frozen pc.

I start to storm again but the only thing I know is:
a) slackware agp nod makes no sense
b) obscure halts during lilo are happening
c) frost login prompts broke with my freebsd zippy cowsay fortune fun

I need some clues or better, a breakpoint hint.

> Date: Sun, 22 Nov 2009 16:48:46 -0500
> From: obrien654j@...
> To: freebsd-hackers@...
> Subject: Cisco Aironet MPI350 Fix
>
> Hello,
>
> I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31, and on a
> fresh install of FreeBSD 8.0-RC3, the card did not work. Also, it caused
> my system to freeze up for a few seconds about once a minute as the
> driver spit out "an0: device timeout" messages so long as the interface
> was up. I researched the issue, and found the following fix already in
> dragonflybsd's tree:
>
> http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db883ae3eb5e4ebf2ece9
>
> I modified the patch and applied it to FreeBSD's kernel (trivial), and
> am happy to report that my card is now working flawlessly. Could someone
> possibly review this patch and integrate it into the source tree so that
> others may benefit from it as well?
>
> The patch is based off of 8.0-RC3's code, but applies to the latest code
> as well without modification.
>
> Thank you,
> Jeremy O'Brien

A vida na frente do computador ficou mais simples: Chegou Windows 7! Clique e Conheça

_________________________________________________________________
Agora a pressa é amiga da perfeição. Chegou o Windows 7. Conheça!
http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-22T21:11:02Z

On Sat, Nov 21, 2009 at 5:52 AM, Peter Jeremy <peterjeremy@...> wrote:
> I did run into problems initially because my i386 userland wasn't
> aligned with my amd64 kernel but rebuilding both fixed that (I'm
> running 8.0-RC1 and a bit).
>
> Note that some tools that poke around in kernel innards won't work -
> ps and lsof are the most obvious. ktrace works but the resultant
> ktrace.out files need to read with an amd64 kdump.

A word of caution: not all the ioctl's and setsockopt's have the
proper glue code under COMBAT_FREEBSD32. For example, running ifconfig
on 7.2 i386-on-amd64 is unable to set an ip address, and syscons
ioctls are completely broken. The program will build properly, but
will be unreliable at runtime (seemingly out of the blue segfaults, a
few cases of sigbus). Especially if they do a blind cast without
sanity checking and confinue forward on error.

While this may not seem that relevant on a build machine, remember
that autoconf generates tiny stub binaries and runs them to determine
'compatibility' for the binary it intends to build. It may feed
information that will lead it to making incorrect guesses about the
target environment. It's not very common, but it has happened, and can
fly under the radar.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

RE: Cisco Aironet MPI350 Fix

2009-11-22T20:17:30Z

Mr O'Brien,

I gave up of 8.0-RC3 a few days ago because I was unable of fix a missing /dev/agp,

but I got better after reading "freeze up a few seconds about once a minute",

just after restart a frozen pc.

I start to storm again but the only thing I know is:

a) slackware agp nod makes no sense

b) obscure halts during lilo are happening

c) frost login prompts broke with my freebsd zippy cowsay fortune fun

I need some clues or better, a breakpoint hint.

_________________________________________________________________
Agora a pressa é amiga da perfeição. Chegou o Windows 7. Conheça!
http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Cisco Aironet MPI350 Fix

2009-11-22T13:48:46Z

Hello,

I have a Cisco Aironet MPI350 PCI card in my Thinkpad X31, and on a
fresh install of FreeBSD 8.0-RC3, the card did not work. Also, it caused
my system to freeze up for a few seconds about once a minute as the
driver spit out "an0: device timeout" messages so long as the interface
was up. I researched the issue, and found the following fix already in
dragonflybsd's tree:

http://gitweb.dragonflybsd.org/dragonfly.git/commit/7a2a04db44efafea257db883ae3eb5e4ebf2ece9

I modified the patch and applied it to FreeBSD's kernel (trivial), and
am happy to report that my card is now working flawlessly. Could someone
possibly review this patch and integrate it into the source tree so that
others may benefit from it as well?

The patch is based off of 8.0-RC3's code, but applies to the latest code
as well without modification.

Thank you,
Jeremy O'Brien

diff --git a/sys/dev/an/if_an.c b/sys/dev/an/if_an.c index 5b4f13b..f08138d 100644 --- a/sys/dev/an/if_an.c +++ b/sys/dev/an/if_an.c @@ -2747,7 +2747,7 @@ an_start(struct ifnet *ifp) struct mbuf *m0 = NULL; struct an_txframe_802_3 tx_frame_802_3; struct ether_header *eh; - int id, idx, i; + int id, idx, i, ready; unsigned char txcontrol; struct an_card_tx_desc an_tx_desc; u_int8_t *buf; @@ -2774,6 +2774,7 @@ an_start(struct ifnet *ifp) return; } + ready = 0; idx = sc->an_rdata.an_tx_prod; AN_LOCK(sc); @@ -2781,6 +2782,7 @@ an_start(struct ifnet *ifp) bzero((char *)&tx_frame_802_3, sizeof(tx_frame_802_3)); while (sc->an_rdata.an_tx_ring[idx] == 0) { + ready = 1; IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); if (m0 == NULL) break; @@ -2803,7 +2805,7 @@ an_start(struct ifnet *ifp) tx_frame_802_3.an_tx_802_3_payload_len, (caddr_t)&sc->an_txbuf); - txcontrol = AN_TXCTL_8023; + txcontrol = AN_TXCTL_8023 | AN_TXCTL_HW(sc->mpi350); /* write the txcontrol only */ an_write_data(sc, id, 0x08, (caddr_t)&txcontrol, sizeof(txcontrol)); @@ -2842,6 +2844,7 @@ an_start(struct ifnet *ifp) while (sc->an_rdata.an_tx_empty || idx != sc->an_rdata.an_tx_cons) { + ready = 1; IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); if (m0 == NULL) { break; @@ -2866,7 +2869,7 @@ an_start(struct ifnet *ifp) tx_frame_802_3.an_tx_802_3_payload_len, (caddr_t)&sc->an_txbuf); - txcontrol = AN_TXCTL_8023; + txcontrol = AN_TXCTL_8023 | AN_TXCTL_HW(sc->mpi350); /* write the txcontrol only */ bcopy((caddr_t)&txcontrol, &buf[0x08], sizeof(txcontrol)); @@ -2888,7 +2891,7 @@ an_start(struct ifnet *ifp) tx_frame_802_3.an_tx_802_3_payload_len; an_tx_desc.an_phys = sc->an_tx_buffer[idx].an_dma_paddr; - for (i = 0; i < sizeof(an_tx_desc) / 4 ; i++) { + for (i = sizeof(an_tx_desc) / 4 - 1; i >= 0; --i) { CSR_MEM_AUX_WRITE_4(sc, AN_TX_DESC_OFFSET /* zero for now */ + (0 * sizeof(an_tx_desc)) @@ -2919,7 +2922,7 @@ an_start(struct ifnet *ifp) } AN_UNLOCK(sc); - if (m0 != NULL) + if (!ready) ifp->if_drv_flags |= IFF_DRV_OACTIVE; sc->an_rdata.an_tx_prod = idx; diff --git a/sys/dev/an/if_anreg.h b/sys/dev/an/if_anreg.h index 103572a..8f3d30a 100644 --- a/sys/dev/an/if_anreg.h +++ b/sys/dev/an/if_anreg.h @@ -394,13 +394,16 @@ struct an_txframe_802_3 { #define AN_PAYLOADTYPE_ETHER 0x0000 #define AN_PAYLOADTYPE_LLC 0x0010 -#define AN_TXCTL_80211 \ - (AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_HEADERTYPE_80211| \ - AN_PAYLOADTYPE_LLC|AN_TXCTL_NORELEASE) +#define AN_TXCTL_80211 (AN_HEADERTYPE_80211|AN_PAYLOADTYPE_LLC) -#define AN_TXCTL_8023 \ - (AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_HEADERTYPE_8023| \ - AN_PAYLOADTYPE_ETHER|AN_TXCTL_NORELEASE) +#define AN_TXCTL_8023 (AN_HEADERTYPE_8023|AN_PAYLOADTYPE_ETHER) + +/* + * Additions to transmit control bits for MPI350 + */ + +#define AN_TXCTL_HW(x) ( x ? (AN_TXCTL_NORELEASE) : \ + (AN_TXCTL_TXOK_INTR|AN_TXCTL_TXERR_INTR|AN_TXCTL_NORELEASE)) #define AN_TXGAP_80211 0 #define AN_TXGAP_8023 0

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: PUFFS SoC project?

2009-11-21T16:14:22Z

On (21/11/2009 21:40), Ivan Voras wrote:
> What is the status of this year's SoC projects? Specifically, does
> anyone know what happened to PUFFS?
> (http://wiki.freebsd.org/SOC2009TatsianaSeveryna) ?
As far as I know it is in a pretty good shape. Tatsiana is busy with
real job, and has "passed" maintainership to me.

ntfs-3g, puffs-ssh and some other filesystems work, but are largely
untested, some fuse filesystems are broken as their support of inode
numbers is to weak (take a look at fuse-sshfs).

There are some issues regarding cache. Original NetBSD puffs code tends
to mmap data to cache it in vm, puffs port doesn't. Besides mmaped pages
can go out of sync.

If you are interested in working on it, do not hesitate contacting me,
I'm interested in finishing the port.

Thanks,
Gleb.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

PUFFS SoC project?

2009-11-21T12:40:37Z

What is the status of this year's SoC projects? Specifically, does
anyone know what happened to PUFFS?
(http://wiki.freebsd.org/SOC2009TatsianaSeveryna) ?
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-21T09:54:32Z

> Note that some tools that poke around in kernel innards won't work -
> ps and lsof are the most obvious. ktrace works but the resultant
> ktrace.out files need to read with an amd64 kdump.

Some of those issues can be solved by using within 32-bit jail
statically linked 64-bit binaries. It does work for ps which is
available in /rescue .

--Artem
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-21T02:52:44Z

On 2009-Nov-19 17:12:19 -0600, "Sam Fourman Jr." <sfourman@...> wrote:
>I would like to help get this working.. is there a howto somewhere to
>setup a i386 jail on amd64?
>I used teh instructions on http://wiki.freebsd.org/Wine (and pointed
>the jail to /compat/i386)

I haven't tried wine, but I do have an i386 jail on my main amd64
server (primarily to build apps for my netbook) and have managed to
build all the apps I want (including Firefox, OpenOffice.org and
jdk15). I have a full i386 world installed in the jail and have
the following overrides in my environment:
MACHINE=i386
UNAME_p=i386
UNAME_m=i386

I did run into problems initially because my i386 userland wasn't
aligned with my amd64 kernel but rebuilding both fixed that (I'm
running 8.0-RC1 and a bit).

Note that some tools that poke around in kernel innards won't work -
ps and lsof are the most obvious. ktrace works but the resultant
ktrace.out files need to read with an amd64 kdump.

>Inside teh jail uname -a still produces this:
>FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18
>22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64

You are missing the UNAME_x environment variables.

>so trying to compile mesa-demos produces this

It will compile and run with the above environment changes.

--
Peter Jeremy

attachment0 (203 bytes) Download Attachment

Re: Wine on amd64 in 32 bit jail

2009-11-21T01:01:59Z

KAYVEN RIESE <skayve@...> wrote:
> Is there any reason to fear Microsoft viruses infecting Wine programs?

In principle, yes, because Wine is supposed to be a complete
reimplementation of the win32 API, thus any program that runs
differently on Wine than on Windows demonstrates a bug in Wine.
(IIRC there are a few Windows viruses that do run on wine.)

In practice, any Wine bug that impairs only viruses will probably
not be a high priority to get fixed :)
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-20T16:27:48Z

KAYVEN RIESE wrote:

>
> On Thu, 19 Nov 2009, Julian Elischer wrote:
>> xorquewasp@... wrote:
>>> On 2009-11-18 23:19:14, Julian Elischer wrote:
>
>>>> Wine is an exceptional bit of software, in many ways.
>
>>> http://wiki.freebsd.org/Wine
>>>
>>> "FreeBSD currently lacks support for 32bit ports on a 64bit system.
>>> However, with a little bit of effort you can build and use the 32 bit
>>> wine executable on an amd64 system (Diablo 2 works just fine)."
>>>
>>> His instructions show an essentially identical setup to mine (apart
>>> from the fact that he's running a chroot and I'm running a jail).
>>
>> jail may not alow you to do the LDT system calls.
>>
>> have you tried a chroot?
>
> Is there any reason to fear Microsoft viruses infecting Wine programs?
> Is that why he is using a jail? Would there be a greater danger of
> virus infection with chroot?

I was thinking just as a test, but others have answered the question I
believe.

>
>
>>
>>>
>>> Even any ideas on how to debug this would help.
>>>
>>> xw
>>
>> _______________________________________________
>> freebsd-hackers@... mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to
>> "freebsd-hackers-unsubscribe@..."
>>
>
> *----------------------------------------------------------*
> Kayven Riese, BSCS, MS (Physiology and Biophysics)
> (415) 902 5513 cellular
> http://kayve.net
> Webmaster http://ChessYoga.org
> *----------------------------------------------------------*
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

RE: Wine on amd64 in 32 bit jail - for stupid peaple only

2009-11-20T15:51:16Z

On Fri, 20 Nov 2009, Fulano Tal wrote:

>
> neither I believe I was sober, bleh :P
>
>
>
> Underdog - planning to write a book now

S00per! {:D what's it gonna be called?

>
>
>
>> Date: Fri, 20 Nov 2009 10:43:17 -0800
>> From: julian@...
>> To: gatinhodosseussonhos@...
>> CC: freebsd-hackers@...
>> Subject: Re: Wine on amd64 in 32 bit jail - for stupid peaple only
>>
>> Fulano Tal wrote:
>>> Use IPMI to read architecture information is easy, but a nice ploy
>> is to sed-out i386 and amd64 related #ifdefs, and have nightmares with
>> chains... sorry, I mean You will have a bi-archtecture system after
>> some work with a cool new personalized tables compatible with 32 and
>> 64 images. You will have the honorable scout's ribbon of scratch a
>> file system in your chest after stark in short, something like an
>> homunculus with AB positive blood type.
>>>
>>>
>>>
>>>
>>> good luck.
>>>
>>>
>>>
>>>
>>> ps.: Do I waste time sending replies that maybe will not help
>> anybody, with idiot thoughs like: "hey guys, what about we taylor an
>> prototype of an a.i. managed not human operating system, that is not
>> so simple to be handled by any simple person except for a few seconds
>> at every century by prodigy minds more exceptional than any existing
>> mythological wisdom, and without any crt and hack objects or strange
>> acpi boring dependencies that nobody want to explain, just to perform
>> the simple task of running other two kernels, like a freebsd code at
>> cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel
>> force balancing shared jobs of an world wide clustered extensible system?"
>>>
>>>
>>> nevermind.
>>>
>>
>> Didn't your mother tell you to not eat other people's medications?
>>
>>
>> :-)
>>
>> Julian
>>
>> _______________________________________________
>> freebsd-hackers@... mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."
>
> _________________________________________________________________
> Agora a pressa é amiga da perfeição. Chegou o Windows 7. Conheça!
> http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539_______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."
>

*----------------------------------------------------------*
Kayven Riese, BSCS, MS (Physiology and Biophysics)
(415) 902 5513 cellular
http://kayve.net
Webmaster http://ChessYoga.org
*----------------------------------------------------------*
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-20T15:17:47Z

On Thu, 19 Nov 2009, Julian Elischer wrote:
> xorquewasp@... wrote:
>> On 2009-11-18 23:19:14, Julian Elischer wrote:

>>> Wine is an exceptional bit of software, in many ways.

>> http://wiki.freebsd.org/Wine
>>
>> "FreeBSD currently lacks support for 32bit ports on a 64bit system.
>> However, with a little bit of effort you can build and use the 32 bit
>> wine executable on an amd64 system (Diablo 2 works just fine)."
>>
>> His instructions show an essentially identical setup to mine (apart
>> from the fact that he's running a chroot and I'm running a jail).
>
> jail may not alow you to do the LDT system calls.
>
> have you tried a chroot?

Is there any reason to fear Microsoft viruses infecting Wine programs? Is
that why he is using a jail? Would there be a greater danger of virus
infection with chroot?

>
>>
>> Even any ideas on how to debug this would help.
>>
>> xw
>
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."
>

RE: Wine on amd64 in 32 bit jail - for stupid peaple only

2009-11-20T11:08:25Z

neither I believe I was sober, bleh :P

Underdog - planning to write a book now

> Date: Fri, 20 Nov 2009 10:43:17 -0800
> From: julian@...
> To: gatinhodosseussonhos@...
> CC: freebsd-hackers@...
> Subject: Re: Wine on amd64 in 32 bit jail - for stupid peaple only
>
> Fulano Tal wrote:
> > Use IPMI to read architecture information is easy, but a nice ploy
> is to sed-out i386 and amd64 related #ifdefs, and have nightmares with
> chains... sorry, I mean You will have a bi-archtecture system after
> some work with a cool new personalized tables compatible with 32 and
> 64 images. You will have the honorable scout's ribbon of scratch a
> file system in your chest after stark in short, something like an
> homunculus with AB positive blood type.
> >
> >
> >
> >
> > good luck.
> >
> >
> >
> >
> > ps.: Do I waste time sending replies that maybe will not help
> anybody, with idiot thoughs like: "hey guys, what about we taylor an
> prototype of an a.i. managed not human operating system, that is not
> so simple to be handled by any simple person except for a few seconds
> at every century by prodigy minds more exceptional than any existing
> mythological wisdom, and without any crt and hack objects or strange
> acpi boring dependencies that nobody want to explain, just to perform
> the simple task of running other two kernels, like a freebsd code at
> cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel
> force balancing shared jobs of an world wide clustered extensible system?"
> >
> >
> > nevermind.
> >
>
> Didn't your mother tell you to not eat other people's medications?
>
>
> :-)
>
> Julian
>
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail - for stupid peaple only

2009-11-20T10:43:17Z

Fulano Tal wrote:
> Use IPMI to read architecture information is easy, but a nice ploy
is to sed-out i386 and amd64 related #ifdefs, and have nightmares with
chains... sorry, I mean You will have a bi-archtecture system after
some work with a cool new personalized tables compatible with 32 and
64 images. You will have the honorable scout's ribbon of scratch a
file system in your chest after stark in short, something like an
homunculus with AB positive blood type.

>
>
>
>
> good luck.
>
>
>
>
> ps.: Do I waste time sending replies that maybe will not help

anybody, with idiot thoughs like: "hey guys, what about we taylor an
prototype of an a.i. managed not human operating system, that is not
so simple to be handled by any simple person except for a few seconds
at every century by prodigy minds more exceptional than any existing
mythological wisdom, and without any crt and hack objects or strange
acpi boring dependencies that nobody want to explain, just to perform
the simple task of running other two kernels, like a freebsd code at
cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel
force balancing shared jobs of an world wide clustered extensible system?"
>
>
> nevermind.
>

Didn't your mother tell you to not eat other people's medications?

:-)

Julian

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

RE: Wine on amd64 in 32 bit jail - for stupid peaple only

2009-11-20T05:31:18Z

Use IPMI to read architecture information is easy, but a nice ploy is to sed-out i386 and amd64 related #ifdefs, and have nightmares with chains... sorry, I mean You will have a bi-archtecture system after some work with a cool new personalized tables compatible with 32 and 64 images. You will have the honorable scout's ribbon of scratch a file system in your chest after stark in short, something like an homunculus with AB positive blood type.

good luck.

ps.: Do I waste time sending replies that maybe will not help anybody, with idiot thoughs like: "hey guys, what about we taylor an prototype of an a.i. managed not human operating system, that is not so simple to be handled by any simple person except for a few seconds at every century by prodigy minds more exceptional than any existing mythological wisdom, and without any crt and hack objects or strange acpi boring dependencies that nobody want to explain, just to perform the simple task of running other two kernels, like a freebsd code at cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel force balancing shared jobs of an world wide clustered extensible system?"

nevermind.

> Date: Fri, 20 Nov 2009 03:29:56 +0000
> From: xorquewasp@...
> To: sfourman@...
> CC: freebsd-hackers@...
> Subject: Re: Wine on amd64 in 32 bit jail
>
> On 2009-11-19 17:12:19, Sam Fourman Jr. wrote:
> >
> > I would like to help get this working.. is there a howto somewhere to
> > setup a i386 jail on amd64?
> > I used teh instructions on http://wiki.freebsd.org/Wine (and pointed
> > the jail to /compat/i386)
> > Inside teh jail uname -a still produces this:
> > FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18
> > 22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64
>
> Hello.
>
> Not sure about the mesa problem at the moment, but I made uname identify
> itself as i386 by just setting UNAME_m=i386 in the environment.
>
> You could put this in the shell environment of the user you run as inside
> the jail.
>
> xw
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

_________________________________________________________________
Novo windowslive.com.br. Descubra como juntar a galera com os produtos Windows Live.
http://www.windowslive.com.br/?ocid=WindowsLive09_MSN_Hotmail_Tagline_out09_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-19T19:29:56Z

On 2009-11-19 17:12:19, Sam Fourman Jr. wrote:
>
> I would like to help get this working.. is there a howto somewhere to
> setup a i386 jail on amd64?
> I used teh instructions on http://wiki.freebsd.org/Wine (and pointed
> the jail to /compat/i386)
> Inside teh jail uname -a still produces this:
> FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18
> 22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64

Hello.

Not sure about the mesa problem at the moment, but I made uname identify
itself as i386 by just setting UNAME_m=i386 in the environment.

You could put this in the shell environment of the user you run as inside
the jail.

xw
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-19T15:12:19Z

On Thu, Nov 19, 2009 at 12:57 AM, <xorquewasp@...> wrote:

> Hello.
>
> I've done a lot of reading on this problem and don't understand why what I have
> doesn't work.
>
> http://wiki.freebsd.org/Wine
>
> I have an entirely 32 bit jail, created by cross-compiling the world with
> TARGET=i386 and creating a jail from DESTDIR.
>
> The jail appears to be fully functional - all programs appear to work and
> the compiler produces i386 binaries.
>
> 'uname' has been configured to identify itself as 'i386', so even compiling
> programs from source works (autoconf correctly recognises the jail system
> as i386, etc).

I would like to help get this working.. is there a howto somewhere to
setup a i386 jail on amd64?
I used teh instructions on http://wiki.freebsd.org/Wine (and pointed
the jail to /compat/i386)
Inside teh jail uname -a still produces this:
FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18
22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64

so trying to compile mesa-demos produces this

/../../src/mesa/x86-64/glapi_x86-64.S:29003: Error: suffix or operands
invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29004: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29005: Error: `6128(%rax)' is
not a valid 32 bit base/index expression
../../../src/mesa/x86-64/glapi_x86-64.S:29006: Error: bad register name `%r11'
../../../src/mesa/x86-64/glapi_x86-64.S:29040: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29041: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29042: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29043: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29044: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29046: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29047: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29048: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29049: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29050: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29051: Error: `6136(%rax)' is
not a valid 32 bit base/index expression
../../../src/mesa/x86-64/glapi_x86-64.S:29052: Error: bad register name `%r11'
../../../src/mesa/x86-64/glapi_x86-64.S:29086: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29087: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29088: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29090: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29091: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29092: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29093: Error: `6144(%rax)' is
not a valid 32 bit base/index expression
../../../src/mesa/x86-64/glapi_x86-64.S:29094: Error: bad register name `%r11'
../../../src/mesa/x86-64/glapi_x86-64.S:29124: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29125: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29126: Error: suffix or
operands invalid for `push'
../../../src/mesa/x86-64/glapi_x86-64.S:29128: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29129: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29130: Error: suffix or
operands invalid for `pop'
../../../src/mesa/x86-64/glapi_x86-64.S:29131: Error: `6152(%rax)' is
not a valid 32 bit base/index expression
../../../src/mesa/x86-64/glapi_x86-64.S:29132: Error: bad register name `%r11'
gmake[2]: *** [../../../src/mesa/x86-64/glapi_x86-64.o] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/mesa-demos/work/Mesa-7.4.4/src/glx/x11'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/usr/ports/graphics/mesa-demos/work/Mesa-7.4.4/src'
gmake: *** [default] Error 1
*** Error code 1

Sam Fourman Jr.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T12:15:35Z

That's it! Thanks! Problem solved :-)

Jay

On Thu, Nov 19, 2009 at 5:34 PM, Dan Nelson <dnelson@...> wrote:

> In the last episode (Nov 19), Koffie Yahoo said:
>> > It's not as portable as getrusage(2), but you could probably get the
>> > information you want using libkvm's kvm_getprocs(3) function. The
>> > information available is defined in the kinfo_proc structure in
>> > /usr/include/sys/user.h.
>>
>> Unfortunately, as far as I can see the kinfo_proc structure only contains
>> the sum of user time and system time and not the two values separately,
>> or have I missed something?
>
> Take a look at the the ki_rusage struct inside kinfo_proc.
>
> --
> Dan Nelson
> dnelson@...
>

Re: Getting running time of child

2009-11-19T08:34:40Z

In the last episode (Nov 19), Koffie Yahoo said:
> > It's not as portable as getrusage(2), but you could probably get the
> > information you want using libkvm's kvm_getprocs(3) function. The
> > information available is defined in the kinfo_proc structure in
> > /usr/include/sys/user.h.
>
> Unfortunately, as far as I can see the kinfo_proc structure only contains
> the sum of user time and system time and not the two values separately,
> or have I missed something?

Take a look at the the ki_rusage struct inside kinfo_proc.

--
Dan Nelson
dnelson@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T07:20:14Z

Boris Kochergin <spawk@...> writes:
> It's not as portable as getrusage(2), but you could probably get the
> information you want using libkvm's kvm_getprocs(3) function. The
> information available is defined in the kinfo_proc structure in
> /usr/include/sys/user.h.

Read the original post.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T07:15:54Z

> It's not as portable as getrusage(2), but you could probably get the
> information you want using libkvm's kvm_getprocs(3) function. The
> information available is defined in the kinfo_proc structure in
> /usr/include/sys/user.h.

Unfortunately, as far as I can see the kinfo_proc structure only contains
the sum of user time and system time and not the two values separately,
or have I missed something?

Jay
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T07:11:53Z

Koffie Yahoo wrote:

>>> I've looked but not found (and I hope I'm in the right group here): Is
>>> there a way to get the user time and system time of a /running/ child
>>> from its parent (without having to mount procfs)?
>>>
>> If you have only one child, there's getrusage(2).
>>
>
> Unfortunately, that only works for children that have terminated, not
> for active children. I'm interested in active children.
>
> Jay
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."
>

It's not as portable as getrusage(2), but you could probably get the
information you want using libkvm's kvm_getprocs(3) function. The
information available is defined in the kinfo_proc structure in
/usr/include/sys/user.h.

-Boris
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T07:07:50Z

Koffie Yahoo <koffieyahoo@...> writes:
> Unfortunately, that only works for children that have terminated, not
> for active children. I'm interested in active children.

Hmm, we could probably add a ptrace(2) operation, but ptrace(2) is
inherently evil.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T06:52:27Z

>> I've looked but not found (and I hope I'm in the right group here): Is
>> there a way to get the user time and system time of a /running/ child
>> from its parent (without having to mount procfs)?
>
> If you have only one child, there's getrusage(2).

Unfortunately, that only works for children that have terminated, not
for active children. I'm interested in active children.

Jay
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Self-encrypting hard drives

2009-11-19T06:48:41Z

I'm looking into using self-encrypting hard drives (TCG Opal standard) with
FreeBSD. In particular I want to use the auto-lock mode. I can't seem to
find the details regarding how the authentication key is provided to the
drive, and where there is any support in FreeBSD to enable unlocking the
drive for use. Any pointers would be appreciated.

Thanks,
Guy
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-19T06:32:59Z

On Thu, Nov 19, 2009 at 06:27:18AM -0800, Julian Elischer wrote:

> xorquewasp@... wrote:
> >On 2009-11-18 23:19:14, Julian Elischer wrote:
> >>Wine is an exceptional bit of software, in many ways.
> >>One way it is exceptional is that it uses the system in a number of
> >>ways that nothing else does. For example it sets various special
> >>segment register settings and defines several different
> >>segments on the LDT. This is something that is different to some
> >>extent between i386 and amd64 and it is possible that
> >>the code for 386 LDT syscalls under amd64 may not work correctly.
> >>nothing else would test this.
> >>
> >
> >I agree and would also have likely not even tried if it wasn't for
> >reading on FreeBSD's own wiki (amonst other places) that it should
> >actually work fine. I've tried various versions and always get the
> >same result:
> >
> > http://wiki.freebsd.org/Wine
> >
> > "FreeBSD currently lacks support for 32bit ports on a 64bit system.
> > However, with a little bit of effort you can build and use the 32 bit
> > wine executable on an amd64 system (Diablo 2 works just fine)."
> >
> >His instructions show an essentially identical setup to mine (apart
> >from the fact that he's running a chroot and I'm running a jail).
>
> jail may not alow you to do the LDT system calls.

There are no restrictions for the sysarch(I386_GET/SET_LDT), neither

for root-only, nor for inside the jail.

>
> have you tried a chroot?
>
> >
> >Even any ideas on how to debug this would help.
> >
> >xw
>
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

attachment0 (203 bytes) Download Attachment

Re: mprotect(2) clears the flag for whole page which causes program crash.

2009-11-19T06:32:26Z

Sharad Chandra wrote:

> ,---- [Jung-uk Kim wrote:]
> | On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote:
> | > On Tue, 17 Nov 2009, Sharad Chandra wrote:
> | > > Is it known bug or is there any workaround? How will a userland
> | > > process make sure that process will not crash as malloc(3) can
> | > > allocate where ever it get the memory free to use.
> | >
> | > mprotect(2) operates on pages, so you'll want to use mmap(2) and
> | > munmap(2) to allocate and free pages directly rather than
> | > mallac(3), which manages byte ranges from pages managed using those
> | > same interfaces.
> |
> | For example:
> |
> | http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471
> |
>
> Thanks everyone. mmap(2) worked and program did not crash. Only problem with
> it I use only fraction of allocated memory (each request alocate minimum of
> one page and my request is in hundreds), rest is waste of it so no one else
> will get this memory to use. And if a process runs as daemon and makes many
> request, It can hold a lot of it. Just a question floated in mind.

write your own allocator that efficiently divides up the mmapped pages
among several requests?

>
> Many thanks,
> Sharad Chandra
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-19T06:27:18Z

xorquewasp@... wrote:

> On 2009-11-18 23:19:14, Julian Elischer wrote:
>> Wine is an exceptional bit of software, in many ways.
>> One way it is exceptional is that it uses the system in a number of
>> ways that nothing else does. For example it sets various special
>> segment register settings and defines several different
>> segments on the LDT. This is something that is different to some
>> extent between i386 and amd64 and it is possible that
>> the code for 386 LDT syscalls under amd64 may not work correctly.
>> nothing else would test this.
>>
>
> I agree and would also have likely not even tried if it wasn't for
> reading on FreeBSD's own wiki (amonst other places) that it should
> actually work fine. I've tried various versions and always get the
> same result:
>
> http://wiki.freebsd.org/Wine
>
> "FreeBSD currently lacks support for 32bit ports on a 64bit system.
> However, with a little bit of effort you can build and use the 32 bit
> wine executable on an amd64 system (Diablo 2 works just fine)."
>
> His instructions show an essentially identical setup to mine (apart
> from the fact that he's running a chroot and I'm running a jail).

jail may not alow you to do the LDT system calls.

have you tried a chroot?

>
> Even any ideas on how to debug this would help.
>
> xw

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Getting running time of child

2009-11-19T05:27:11Z

Koffie Yahoo <koffieyahoo@...> writes:
> I've looked but not found (and I hope I'm in the right group here): Is
> there a way to get the user time and system time of a /running/ child
> from its parent (without having to mount procfs)?

If you have only one child, there's getrusage(2).

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: header file bug sys/types.h sys/file.h vs. _XOPEN_SOURCE standard

2009-11-19T05:25:10Z

"Matthias Andree" <matthias.andree@...> writes:
> I've talked to Theodore Y. Ts'o, who is the sysutils/e2fsprogs
> upstream maintainer and proposed to remove the _XOPEN_SOURCE
> definition (my idea was that the code shouldn't be claiming standards
> compliance while it uses non-standard headers), but he refused that
> (since it would break the e2fsprogs build on Solaris).

He's right. You misunderstand _XOPEN_SOURCE; it does not mean "my
program complies with X/Open blah", it means "my program requires the
facilities provided by X/Open blah". The problem lies in FreeBSD's
headers, which don't implement namespace separation correctly.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: mprotect(2) clears the flag for whole page which causes program crash.

2009-11-19T03:42:32Z

On 19 Nov 2009, at 10:57, Sharad Chandra wrote:

> Thanks everyone. mmap(2) worked and program did not crash. Only problem with
> it I use only fraction of allocated memory (each request alocate minimum of
> one page and my request is in hundreds), rest is waste of it so no one else
> will get this memory to use. And if a process runs as daemon and makes many
> request, It can hold a lot of it. Just a question floated in mind.

One of the defining properties of pages is that they are the granularity at which access protections are controlled in hardware, so your choices are a minimum of one page per object, or having multiple objects that share the same protection properties. However, it could be that you could accomplish whatever your goals may be using techniques other than paging; for example, using ptrace(2) to instrument individual accesses, binary rewriting, a virtual machine, source code instrumentation, or other methods along those lines that have been used for debugging and security over the years.

Robert_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: mprotect(2) clears the flag for whole page which causes program crash.

2009-11-19T02:57:33Z

,---- [Jung-uk Kim wrote:]
| On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote:
| > On Tue, 17 Nov 2009, Sharad Chandra wrote:
| > > Is it known bug or is there any workaround? How will a userland
| > > process make sure that process will not crash as malloc(3) can
| > > allocate where ever it get the memory free to use.
| >
| > mprotect(2) operates on pages, so you'll want to use mmap(2) and
| > munmap(2) to allocate and free pages directly rather than
| > mallac(3), which manages byte ranges from pages managed using those
| > same interfaces.
|
| For example:
|
| http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471
|

Thanks everyone. mmap(2) worked and program did not crash. Only problem with
it I use only fraction of allocated memory (each request alocate minimum of
one page and my request is in hundreds), rest is waste of it so no one else
will get this memory to use. And if a process runs as daemon and makes many
request, It can hold a lot of it. Just a question floated in mind.

Many thanks,
Sharad Chandra
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Wine on amd64 in 32 bit jail

2009-11-19T02:23:09Z

On 2009-11-19 12:15:18, Kostik Belousov wrote:
> On Thu, Nov 19, 2009 at 09:36:54AM +0000, xorquewasp@... wrote:
>
> It is in 8.0.

Excellent, thanks.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."