[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V4] ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips



On 22/11/13 12:14, Jan Beulich wrote:
>>>> On 22.11.13 at 11:44, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 21/11/13 22:50, Aravind Gopalakrishnan wrote:
>>>      if ( uart->remapped_io_base )
>>> +    {
>>> +        sfn = paddr_to_pfn((unsigned long) uart->io_base + PAGE_SIZE);
>>> +        efn = paddr_to_pfn((unsigned long) uart->io_base + uart->io_size - 
>>> 1);
>>> +        if ( iomem_deny_access(dom0, sfn, efn) != 0 )
>>> +            BUG();
>> BUG_ON(!iomem_deny_access(dom0, sfn, efn))
> Actually, we had more or less agreed to avoid side effects in
> ASSERT() and BUG_ON() expressions (to eliminate the ambiguity
> whether such expressions get always evaluated).

ASSERT()s certain, as the non-debug builds will optimise away call.

BUG/WARN_ON()s are different - they will be executed in all cases.

>
>> is slightly more compact, and has the advantage of showing the action
>> which failed in the BUG message.
> Since when does BUG() should any expression?

Hmm - they don't do they.  I was getting my BUG()s and ASSERTS()s mixed up.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.