Re: FLEX, was Re: Return value of malloc(0)
"Randall Hyde" <[EMAIL PROTECTED]> > > BTW, if anyone is intrested in the full FLEX source, it's part of the HLA > (High Level Assembler) source package found here: > > > http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip > Just wondering if those guys knew that IBM calls their mainframe assembler the "High Level Assembler", which they abbreviate HLASM. This isn't an x86 assembler like HLA - it's a z/Architecture (mainframe) assembler, very different beast indeed. But - they may want to pick a new name, lest they incur the wrath of IBM's lawyers. I think IBM took that name in the 80s. Also - it seems that 'webster.cs.ucr.edu' has gone missing from DNS somehow; so I wasn't able to look at the source, although I was able to look at the web pages thanks to Yahoo's cache. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New architecture support
On Monday 26 June 2006 09:53, Aditya Godbole wrote: > Hi, > > If I have to add support for a new architecture, how do I start? I > guess I need to get the build system and 'config' utility in place? > How do I go about it? Well, you'll need a toolchain. :) Then you can start working on building a minimal kernel filling in missing bits in sys/ as you go. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NVIDIA FreeBSD kernel feature requests
Hi all, NVIDIA has been looking at ways to improve its graphics driver for the FreeBSD i386 platform, as well as investigating the possibility of adding support for the FreeBSD amd64 platform, and identified a number of obstacles. Some progress has been made to resolve them, and NVIDIA would like to summarize the current status. We would also like to thank John Baldwin and Doug Rabson for their valuable help. This summary makes an attempt to describe the kernel interfaces needed by the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with the Linux/Solaris graphics drivers, and/or required to make support for the FreeBSD amd64 platform feasible. It also describes some of the technical difficulties encountered by NVIDIA during the FreeBSD i386 graphics driver's development, how these problems have been worked around and what could be done to solve them better. While the following is focused on the NVIDIA FreeBSD graphics drivers, we believe the interfaces discussed below are generally applicable to any modern high performance graphics driver. The interfaces in question can be loosely categorized into the different classes reliability, compatibility and performance: Reliability: The NVIDIA graphics driver needs to be able to create uncached kernel and user mappings of I/O memory, such as NVIDIA GPU registers. The FreeBSD kernel does not currently provide the interfaces necessary to specify the memory type when creating such mappings, which makes it difficult for the NVIDIA graphics driver to guarantee that the correct memory type is selected. Kernel mappings of I/O memory can be created with the pmap_mapdev() interface, user mappings are created with mmap(2). On FreeBSD i386 and on FreeBSD amd64, the effective memory type of mappings created with either interface is determined by a given system's MTRR configuration by default, which will specify the correct UC memory type in most, but not in all cases. MTRR configurations with non-UC memory ranges overlapping I/O memory mapped via pmap_mapdev() or mmap(2) can result in the incorrect memory type being selected, which can impair reliability. To reduce the likelihood of problems, the FreeBSD i386 driver updates the mappings returned by pmap_mapdev() with the PCD/PWT flags to force use of the UC memory type. On FreeBSD amd64, the presence of a large static mapping using 2MB pages makes this approach unfeasible. In the case of user mappings, limited control over the memory type can be exerted with the help of MTRRs, but their lack of flexibility greatly reduces the feasibility of this approach. 1) The NVIDIA FreeBSD graphics driver is in need of new a interface that supports the creation of UC kernel mappings on FreeBSD i386 and on FreeBSD amd64. John Baldwin is working on a new interface, pmap_mapdev_attr(), which will allow the NVIDIA graphics driver to create UC kernel mappings on FreeBSD i386 and on FreeBSD amd64; the implementation on the latter platform will handle the direct mapping transparently. 2) As described above, user mappings of I/O memory are created via the mmap(2) interface and the FreeBSD device pager; unfortunately, drivers do not currently have control over the memory type used. The NVIDIA FreeBSD graphics driver needs to be able to specify the memory type used for user mappings created via mmap(2). This interface is also important for high performance graphics (see 'Performance' below). Compatibility: 1) The NVIDIA graphics driver needs to be able to set the memory type of the kernel mapping of memory allocated with malloc()/contigmalloc() to UC, which presents essentially the same problems as those outlined above for I/O memory mappings. The ability to change the memory type is necessary to avoid aliasing problems when the memory is mapped into the AGP aperture, which is accessed via WC user mappings. If the creation of UC/WC user mappings becomes possible for system memory in the future (see below), the ability to change the memory type of the associated kernel mappings to UC will be important for the same reason. Newer NVIDIA FreeBSD i386 graphics drivers manually update the memory type of the kernel mappings of malloc() allocated memory using the approach described for kernel mappings above. This is not feasible on FreeBSD amd64 due to the static direct mapping (see above). The NVIDIA FreeBSD graphics driver needs an interface that allows it to change the memory type of the kernel mapping(s) of system memory allocated with malloc()/contigmalloc(). The interface should flush CPU and TLB caches, when necessary. John Baldwin is working on pmap_change_attr() for FreeBSD i386 and for FreeBSD amd64, which will allow specifying the desired memory types for kernel mappings created with e.g. malloc()/contigmalloc(). 2) The NVIDIA graphics driver needs to
Re: Return value of malloc(0)
On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote:
> Andre Albsmeier <[EMAIL PROTECTED]> writes:
>
> >
> > The manpage makes me think that when malloc is called with 0
> > as argument (and no V-flag had been set) the pointer it returns
> > can actually be used (as a pointer to the so-called "minimal
> > allocation"). It seems, that firefox "thinks" the same way :-).
> > However, it is calculated in malloc.c as a constant and is
> > always 0x800 (on my architecture). Any access to this area
> > results in a SIGSEV.
>
> The C standard explicitly allows both behaviours, and requires the
> implementation to choose one of them. If it returns a non-NULL
> pointer, though, that pointer can *only* be used for passing back to
> free(). It may *not* be dereferenced. So firefox is wrong, and
> actually broken.
Very good. I am glad this is clearly defined.
>
> > I assume the behaviour is meant to show up programming errors:
> >
> > "If you use malloc(0) and are crazy enough to access the 'allocated'
> > memory we give you a SIGSEV to show you how dumb you are :-)".
>
> Yes.
>
> > In this case the manpage is wrong (or, at least, mis-leading) and
> > should be fixed (I could give it a try if someone actually is willing
> > to commit it).
>
> I don't see what you are claiming is wrong. Can you give a brief
It says:
"The default behavior is to make a minimal allocation and return
a pointer to it."
This sounds as if it allocated some (!) bytes so the application
can use it. Yes, I know that 0 would be minimal as well :-). And
if you look into malloc.c you will see that, in fact, it doesn't
allocate anything at all:
} else if (!size) {
if (ptr != NULL)
ifree(ptr);
r = ZEROSIZEPTR;
r ist returned later and ZEROSIZEPTR is a constant.
> description of you're suggesting.
Hmm, let's see:
The default behavior is to return a non-NULL pointer which may
be passed to free() but does not point to any memory which can
be used by the application.
>
> > Apart from that, I suggest, we should run firefox (and maybe other
> > mozilla apps) with MALLOC_OPTIONS=V.
>
> That would be reasonable, particularly for the time being. However,
> the firefox bug really should be fixed in the upstream sources.
In this case, yes, of course.
-Andre
> Writing past the end of an allocated buffer (which is what the code
> does, if you think about it) is a serious error.
>
> > Another position could be that firefox is wrong because it NEVER
> > may use ANY return value of a malloc(0), regardless of its content.
>
> The C language standard agrees with this position...
--
Micro$oft: When will your system crash today?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. first = malloc(0) ; second = malloc(0) ; if ( first == second ) ERROR( "C standards violation" ) ; Firefox, or the extension, has a bug in the code. It should not be attempting to de-reference the result of a 'malloc(0)' call. They probably depend on having it return NULL, which is checked elsewhere. (The fix is for them to test for the size == zero case and just set the pointer to NULL instead of calling malloc(0). But that's their problem, not ours.) -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
Johannes Weiner <[EMAIL PROTECTED]> writes: > Hi, > > On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: >> "If you use malloc(0) and are crazy enough to access the 'allocated' >> memory we give you a SIGSEV to show you how dumb you are :-)". > > They should check the return value of malloc() in any case for > successful allocation.. shouldn't they? The value returned from malloc(0) must not be dereferenced whatever it was. It was 0x800, which doesn't count as "failure". -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVIDIA FreeBSD kernel feature requests
Christian Zander wrote: Hi all, # Task:implement mechanism to allow character drivers to maintain per-open instance data (e.g. like the Linux kernel's 'struct file *'). Motivation: allows per thread NVIDIA notification delivery; also reduces CPU overhead for notification delivery from the NVIDIA kernel module to the X driver and to OpenGL. Priority:should translate to improved X/OpenGL performance. Status: has not been started. I've stumbled across this issue a while ago. Actually it can be partially solved using EVENTHANDLER_REGISTER of dev_clone event with keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's the best solution but it works for me though it smells like hack, and looks like hack :) Anyway, having legitimate per-open instance data structures of cdevs is a great assistance in porting linux drivers to FreeBSD. Just my $0.02. -- Sincerely, Oleksandr Tymoshenko PBXpress Communications, Inc. http://www.pbxpress.com Tel./Fax.: +1 866 SIP PBX1 Ext. 656 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: > The value returned from malloc(0) must not be dereferenced whatever it > was. It was 0x800, which doesn't count as "failure". But this would be appropriate for catching the error: if ((foo = malloc(0)) == foo) /* make noise */ wouldn't it? Hannes -- If the telephone rang today, water it! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVIDIA FreeBSD kernel feature requests
IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. -Kip On 6/29/06, Oleksandr Tymoshenko <[EMAIL PROTECTED]> wrote: Christian Zander wrote: > Hi all, > # Task:implement mechanism to allow character drivers to > maintain per-open instance data (e.g. like the Linux > kernel's 'struct file *'). >Motivation: allows per thread NVIDIA notification delivery; also > reduces CPU overhead for notification delivery > from the NVIDIA kernel module to the X driver and to > OpenGL. >Priority:should translate to improved X/OpenGL performance. >Status: has not been started. I've stumbled across this issue a while ago. Actually it can be partially solved using EVENTHANDLER_REGISTER of dev_clone event with keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's the best solution but it works for me though it smells like hack, and looks like hack :) Anyway, having legitimate per-open instance data structures of cdevs is a great assistance in porting linux drivers to FreeBSD. Just my $0.02. -- Sincerely, Oleksandr Tymoshenko PBXpress Communications, Inc. http://www.pbxpress.com Tel./Fax.: +1 866 SIP PBX1 Ext. 656 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Johannes Weiner wrote: JW>On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: JW> JW>> The value returned from malloc(0) must not be dereferenced whatever it JW>> was. It was 0x800, which doesn't count as "failure". JW> JW>But this would be appropriate for catching the error: JW> JW>if ((foo = malloc(0)) == foo) JW> /* make noise */ JW> JW>wouldn't it? Wouldn't it rather invoke undefined behaviour? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: > No, our implementation is NOT legal. We always return the SAME value. To > be legal, we should not return that value again unless it has been > free()-ed. It is legal due to brain damaged definition of implementation defined behaviour, but it violates the spirit of the standard :-) Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
Johannes Weiner <[EMAIL PROTECTED]> writes: > On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: > >> The value returned from malloc(0) must not be dereferenced whatever it >> was. It was 0x800, which doesn't count as "failure". > > But this would be appropriate for catching the error: > > if ((foo = malloc(0)) == foo) > /* make noise */ > > wouldn't it? No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ There is no way to see a 0x800 return from malloc(0) as "error". -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVIDIA FreeBSD kernel feature requests
On Thu, Jun 29, 2006 at 09:32:42AM -0700, Kip Macy wrote: > IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. > >-Kip > > On 6/29/06, Oleksandr Tymoshenko <[EMAIL PROTECTED]> wrote: > >Christian Zander wrote: > >> Hi all, > >> # Task:implement mechanism to allow character drivers to > >> maintain per-open instance data (e.g. like the Linux > >> kernel's 'struct file *'). > >>Motivation: allows per thread NVIDIA notification delivery; also > >> reduces CPU overhead for notification delivery > >> from the NVIDIA kernel module to the X driver and to > >> OpenGL. > >>Priority:should translate to improved X/OpenGL performance. > >>Status: has not been started. > > I've stumbled across this issue a while ago. Actually it can > >be partially solved using EVENTHANDLER_REGISTER of dev_clone event with > >keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's > >the best solution but it works for me though it smells like hack, and > >looks like hack :) Anyway, having legitimate per-open instance data > >structures of cdevs is a great assistance in porting linux drivers to > >FreeBSD. Just my $0.02. > > WHY it smells like a hack? It was designed precisely to do that. I am using cloned devices in our product with great success. Every client opening 'magic' device gets its own exclusive cloned device instance and everything works like a charm. I am yet to hear any single coherent description of what Linux's approach has over device cloning in FreeBSD. I wouldn't mind being educated on this. -- Alexander Kabaev pgpQ6tQSpB5xt.pgp Description: PGP signature
Re: NVIDIA FreeBSD kernel feature requests
On Thu, Jun 29, 2006 at 12:49:10PM -0400, Alexander Kabaev wrote: > On Thu, Jun 29, 2006 at 09:32:42AM -0700, Kip Macy wrote: > > IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. > > > >-Kip > > > > On 6/29/06, Oleksandr Tymoshenko <[EMAIL PROTECTED]> wrote: > > >Christian Zander wrote: > > >> Hi all, > > >> # Task:implement mechanism to allow character drivers to > > >> maintain per-open instance data (e.g. like the Linux > > >> kernel's 'struct file *'). > > >>Motivation: allows per thread NVIDIA notification delivery; also > > >> reduces CPU overhead for notification delivery > > >> from the NVIDIA kernel module to the X driver and to > > >> OpenGL. > > >>Priority:should translate to improved X/OpenGL performance. > > >>Status: has not been started. > > > I've stumbled across this issue a while ago. Actually it can > > >be partially solved using EVENTHANDLER_REGISTER of dev_clone event with > > >keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's > > >the best solution but it works for me though it smells like hack, and > > >looks like hack :) Anyway, having legitimate per-open instance data > > >structures of cdevs is a great assistance in porting linux drivers to > > >FreeBSD. Just my $0.02. > > > > > WHY it smells like a hack? It was designed precisely to do that. I am > using cloned devices in our product with great success. Every client > opening 'magic' device gets its own exclusive cloned device instance > and everything works like a charm. I am yet to hear any single coherent > description of what Linux's approach has over device cloning in FreeBSD. > I wouldn't mind being educated on this. > Thanks for your feedback, I hadn't been aware of this interface, but it sounds promising. When was it first introduced? Are there any known problems with it and certain FreeBSD releases, or is it expected to work fine in FreeBSD >= 5.3? Thanks, > -- > Alexander Kabaev -- christian zander [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Matthias Andree wrote: MA>Johannes Weiner <[EMAIL PROTECTED]> writes: MA> MA>> On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: MA>> MA>>> The value returned from malloc(0) must not be dereferenced whatever it MA>>> was. It was 0x800, which doesn't count as "failure". MA>> MA>> But this would be appropriate for catching the error: MA>> MA>> if ((foo = malloc(0)) == foo) MA>>/* make noise */ MA>> MA>> wouldn't it? MA> MA>No, sir. Operator precedence: assign first, and then compare, thus the MA>comparison will always be true (else you'd be comparing to undefined MA>values, which isn't any better). You might as well write: Operator precedence is just for parsing, not for evaluation. The compiler may well first evaluate the foo on the right side of the == (by fetching it) and then go an call malloc and assign foo. It is actually undefined behaviour, I think, so it may well make explode your near-by atom power plant. harti MA> MA> foo = malloc(0); MA> /* make noise */ MA> MA>There is no way to see a 0x800 return from malloc(0) as "error". MA> MA> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: checking zip file corruption
Thank you for the suggestion. On 6/26/06, Craig Rodrigues <[EMAIL PROTECTED]> wrote: On Mon, Jun 26, 2006 at 09:18:31AM -0400, Ashok Shrestha wrote: > Hi all, > > I am writing code to check if incoming zip files are corrupt and the > client is not willing to send a digest (like md5) of the file. Why don't you just use InfoZip's "unzip -t" flag which tests the integrity of a zip file? You can call "unzip -t" from Perl. InfoZip is in ports, archivers/unzip and archivers/zip. -- Craig Rodrigues [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVIDIA FreeBSD kernel feature requests
Alexander Kabaev wrote: WHY it smells like a hack? It was designed precisely to do that. I am using cloned devices in our product with great success. Every client opening 'magic' device gets its own exclusive cloned device instance and everything works like a charm. I am yet to hear any single coherent description of what Linux's approach has over device cloning in FreeBSD. I wouldn't mind being educated on this. OK, it's a lack of my knowledge. It seemed a bit unnatural to me to create device nodes instead of keeping a single pointer and I decided it was supposed to do something other then keeping per-open instance. It would be great to have this event/mechanism documented for I'd found it looking through source code in /usr/src/sys. Not the worst place to get information but man pages are better :) -- Sincerely, Oleksandr Tymoshenko PBXpress Communications, Inc. http://www.pbxpress.com Tel./Fax.: +1 866 SIP PBX1 Ext. 656 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: > >The C Standard says the following about malloc(0): > > > > If the size of the space requested is zero, the behavior is > > implementation-defined: either a null pointer is returned, or the > > behavior is as if the size were some nonzero value, except that the > > returned pointer shall not be used to access an object. > > > >So our default behaviour to crash if a pointer returned by malloc(0) is > >dereferenced is legal and a good one because it catches errors like the > >above one. > > No, our implementation is NOT legal. We always return the SAME value. To > be legal, we should not return that value again unless it has been > free()-ed. > >first = malloc(0) ; >second = malloc(0) ; > >if ( first == second ) ERROR( "C standards violation" ) ; Almost. The test should be if ( first != NULL && first == second) ERROR( "C standards violation" ) ; It is after all legal for malloc(0) to return NULL. Otherwise you are correct. Having malloc(0) always returning the same (non-NULL) value is not legal according to the C standard. C99 says: 7.20.3 Memory management functions [...] Each such allocation shall yield a pointer to an object disjoint from any other object. [...] If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. > > > Firefox, or the extension, has a bug in the code. It should not be > attempting to de-reference the result of a 'malloc(0)' call. They probably > depend on having it return NULL, which is checked elsewhere. (The fix is > for them to test for the size == zero case and just set the pointer to NULL > instead of calling malloc(0). But that's their problem, not ours.) > > > > -Pat > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: > No, our implementation is NOT legal. We always return the SAME value. To > be legal, we should not return that value again unless it has been > free()-ed. It is legal due to brain damaged definition of implementation defined behaviour, but it violates the spirit of the standard :-) Perhaps I'm misunderstanding the 'implementation defined behavior' choices in the standard. I thought that it could either 1) Return NULL; or 2) Behave as though it returned a 'minimum allocation' (which cannot be legally de-referenced). But if it did actually perform a 'minimum allocation'; wouldn't it have to return a different value every time to maintain the free() semantics? -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NVIDIA FreeBSD kernel feature requests
Christian Zander wrote: > On Thu, Jun 29, 2006 at 12:49:10PM -0400, Alexander Kabaev wrote: >> On Thu, Jun 29, 2006 at 09:32:42AM -0700, Kip Macy wrote: >>> IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. >>> >>>-Kip >>> >>> On 6/29/06, Oleksandr Tymoshenko <[EMAIL PROTECTED]> wrote: Christian Zander wrote: > Hi all, > # Task:implement mechanism to allow character drivers to > maintain per-open instance data (e.g. like the Linux > kernel's 'struct file *'). >Motivation: allows per thread NVIDIA notification delivery; also > reduces CPU overhead for notification delivery > from the NVIDIA kernel module to the X driver and to > OpenGL. >Priority:should translate to improved X/OpenGL performance. >Status: has not been started. I've stumbled across this issue a while ago. Actually it can be partially solved using EVENTHANDLER_REGISTER of dev_clone event with keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's the best solution but it works for me though it smells like hack, and looks like hack :) Anyway, having legitimate per-open instance data structures of cdevs is a great assistance in porting linux drivers to FreeBSD. Just my $0.02. >> WHY it smells like a hack? It was designed precisely to do that. I am >> using cloned devices in our product with great success. Every client >> opening 'magic' device gets its own exclusive cloned device instance >> and everything works like a charm. I am yet to hear any single coherent >> description of what Linux's approach has over device cloning in FreeBSD. >> I wouldn't mind being educated on this. >> > > Thanks for your feedback, I hadn't been aware of this interface, but > it sounds promising. When was it first introduced? Are there any > known problems with it and certain FreeBSD releases, or is it expected > to work fine in FreeBSD >= 5.3? It came in with devfs so it should be in all 5.x systems. Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
Pat Lashley <[EMAIL PROTECTED]> writes: >> On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: >> > No, our implementation is NOT legal. We always return the SAME value. To >> > be legal, we should not return that value again unless it has been >> > free()-ed. >> >> It is legal due to brain damaged definition of implementation defined >> behaviour, but it violates the spirit of the standard :-) > > Perhaps I'm misunderstanding the 'implementation defined behavior' > choices in the standard. I thought that it could either 1) Return > NULL; or 2) Behave as though it returned a 'minimum allocation' (which > cannot be legally de-referenced). I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that "unique" meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. Specifically: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. >But if it did actually perform a > minimum allocation'; wouldn't it have to return a different value > every time to maintain the free() semantics? I think that's another way of looking at the same confusion. If "minimum" is zero, then using a sentinel value (as in FreeBSD) works. Our malloc() could be easily fixed to be standards-compliant by removing the special handling for ZEROSIZEPTR in malloc.c; then allocations of 0 bytes will be rounded up to 16, just like all other alloations of less than 16 bytes. However, that would lose much of the bug-finding advantage of the current behaviour. This is wandering into -standards territory, though. In any case, the answer to thread's original question is "mozilla should fix its code to not assume malloc(0)==NULL". ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FLEX, was Re: Return value of malloc(0)
-Original Message- > >How about feeding the C source through the preprocessor, stripping out >the #line directives, compiling it and posting the exact gcc error and >source context. Okay, I'll try that when I get home. But I was kind of under the impression that *GCC* runs the preprocessor on the input, during compilation :-). > >It may be a gcc bug, it may be a HLA bug or it could be an interaction >between the FreeBSD headers and HLA. None of the code listed has *anything* to do with the HLA.FLX source (and certainly nothing to do with the rest of the HLA source code). It is quite possible that some FreeBSD headers conflict with this section of the FLEX output (remember, this is *canned* output code from FLEX, this is not generated in response to any FLEX input code). That's why my original question was so generic and not specific -- this would appear to be a generic problem with using FLEX output under BSD and I thought a quick question would affirm/deny that thought. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FLEX, was Re: Return value of malloc(0)
-Original Message- >From: Thomas David Rivers <[EMAIL PROTECTED]> >Sent: Jun 29, 2006 3:17 AM >To: freebsd-hackers@freebsd.org, [EMAIL PROTECTED] >Subject: Re: FLEX, was Re: Return value of malloc(0) > >"Randall Hyde" <[EMAIL PROTECTED]> >> >> BTW, if anyone is intrested in the full FLEX source, it's part of the HLA >> (High Level Assembler) source package found here: >> >> >> http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip >> > >Just wondering if those guys knew that IBM calls their mainframe assembler >the "High Level Assembler", which they abbreviate HLASM. These guys would be just me, and I'm quite aware of HLASM. Of course, the term "High Level Assembler" predated IBM's HLASM by many years (indeed, the phrase was used a bit in the late 1960s, see Salomon's book for details). > >This isn't an x86 assembler like HLA - it's a z/Architecture >(mainframe) assembler, very different beast indeed. Yes, their concept of "High Level" meant fancy macro facilities. Not back for a 1980's-era assembler. > >But - they may want to pick a new name, lest they incur the wrath >of IBM's lawyers. I think IBM took that name in the 80s. Again, the generic term High Level Assembler predated HLASM, and HLA and HLASM are two different things. Further, there was an HLA for the Amiga some time back. Again, it's not like this term is terribly original. And I seriously doubt if IBM really cares at this point. > >Also - it seems that 'webster.cs.ucr.edu' has gone missing >from DNS somehow; so I wasn't able to look at the source, although >I was able to look at the web pages thanks to Yahoo's cache. Hmmm... Webster is a relatively famous site, so that's unusual. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help:why bus resource shortage?
[EMAIL PROTECTED] wrote this message on Thu, Jun 15, 2006 at 14:55 +0800: > I failed to get the pci bus resource after the driver is loaded (sc->r_mem > is NULL after bus_alloc_resource_any is called). Is it because bus resources > have been consumed by other drivers? Or other something happened? Please > help me on this! Please provide a verbose boot (boot -v) output of the pci card... > rid = 0x10; You really should be using PCIR_BAR macro instead of hard coding it... > sc->r_mem = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid, > RF_ACTIVE); > > if (!sc->r_mem) return ENOMEM; > > > > The pci resources on our cards: > > shasta0: port 0x2400-0x247f, > 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe900-0xe901 irq 17 at > device 5.0 on pci2 The resources could be in a different order than listed... Are you sure the memory resource is in the first bar possition? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Harti Brandt wrote: > Operator precedence is just for parsing, not for evaluation. The > compiler may well first evaluate the foo on the right side of the == (by > fetching it) and then go an call malloc and assign foo. Right, thanks for reminding me. I don't usually write code that depends on evaluation order... except with the short-circuiting stuff || or &&. splint 3.1.1 complains about this issue BTW, but neither GCC 4.1.0 nor ICC 8.1.028 on Linux nor FreeBSD lint complain. I used gcc -Wall which is specified to include -Wsequence-point... > It is actually undefined behaviour, I think, so it may well make explode > your near-by atom power plant. It had better not... -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Return value of malloc(0)
Hi, On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote: > No, sir. Operator precedence: assign first, and then compare, thus the > comparison will always be true (else you'd be comparing to undefined > values, which isn't any better). You might as well write: > > foo = malloc(0); > /* make noise */ Ok, just for having it done: if (foo == (foo = some_val)) .. would be right to check if foo stayed the same. No? > There is no way to see a 0x800 return from malloc(0) as "error". So noone should actually use malloc(0) and check the size_t argument before passing it, I guess. Hannes -- One must still have chaos in oneself to be able to give a birth to a dancing star. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New architecture support
On 6/27/06, John Baldwin <[EMAIL PROTECTED]> wrote: > If I have to add support for a new architecture, how do I start? Well, you'll need a toolchain. :) Then you can start working on building a minimal kernel filling in missing bits in sys/ as you go. Is there any documentation regarding the interface between the machine independant and machine dependant parts of the kernel. Also what functionality does the machine independant part expect to be in place? -aditya ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
