* Use string keys. I am still convinced we need BValue.
* Use boolean instead of status_t in return, this is
much more handy in pratical use given that there's no
really a status to check.
On my VMware Player installation, the device ID is "1977", but presumably
VMware will have only one HDA codebase, and so we just enable the fix on
all devices.
This fixes initialization of the HDA driver on VMware, and means that
it is now possible to get sound output on VMware without using the
OpenSound driver package.
The paths to tools are relative to cwd, and HAIKU_ABSOLUTE_OUTPUT_DIR is
not necessarily the same as that, in the case where jam is invoked from
the repository root instead of a "generated" directory.
HOST_OBJECT_BASE_DIR is relative to pwd also, so just make it absolute.
Change-Id: I2aef83804be31c3c03c8577d56372f2dc6cb77f8
Reviewed-on: https://review.haiku-os.org/718
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Waiting of worker threads in IMAPProtocol destructor introducred new deadlocks.
For example: fWorkerLock grabbed in destructor leads to deadlock with
CheckSubscribedFoldersCommand (which grabs this lock with flock grabbed).
So, currently it should be reverted.
Change-Id: Ibc4b4f85300352e045d4ce72deb804e0e613f25c
Reviewed-on: https://review.haiku-os.org/714
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Those classes are not ready for public consumption. Ideally,
I'd add a well designed BCodecRoster wrapping them. This is part
of the general cleanup I am doing to get the code in a good state
before going to finalize the design.
* I don't plan to reintroduce BMediaFile in the media2 API, and
I'd like to remove any (explicit) usage of entry_refs and things
like that.
* I plan to introduce BMetaData and BMediaFormat which is going
to be different than what we do now.
* We need to explicitly use the mime type when it's available and
it is another design consideration when CodecRoster will be introduced.
Otherwise, create_area fails with "Invalid Argument." Should fix the
"empty directory in userlandfs mount" bug that has been appearing
since the cloneable-area fixes.
Change-Id: I26e73539a9f345e76b22a34a68fe4b49c63683c2
Reviewed-on: https://review.haiku-os.org/707
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously this protection was possible via the opt-in B_KERNEL_AREA flag,
however, almost nothing used that, so in practice these protections were
rarely enforced.
Userland can still access kernel areas according to the protection flags
(and due to SMAP, these have been refined and reduced as appopriate)
and clone them (according to B_USER_CLONEABLE_AREA flag, which has
been required since August of this year), but they can no longer
resize them (something no in-tree application does on any shared area),
set protections (otherwise they could add B_USER_CLONEABLE_AREA...),
unmap them, or essentially do anything else besides get their
information (and even that we should restrict to uid 0, in the future.)
From my testing, this does not introduce any issues, and no applications
nor drivers should have been relying on the previous behavior (unlike
SMAP or the clone-area changes, which did affect applications.)
* Slightly change the formula for bigger sizes (use real width).
Change-Id: I66204c2727f30e3f139b506174e287811c258fa9
Reviewed-on: https://review.haiku-os.org/704
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
fLocker must be released in IMAPConnectionWorker::_Worker() before WorkerQuit() call.
Change-Id: I1e622a711fa3349986560af1118b158696025844
Reviewed-on: https://review.haiku-os.org/705
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
- if fText is an empty string, we would start searching past its end,
possibly leading to a crash (noticed this in HaikuDepot).
- if fText is NULL, BString would report a size of 0 lines, it makes
more sense to report a size of 1 line.
* First re-fix of what was reverted in 85f8e7001
* haikuporter calls these during bootstrap and needs absolute paths
Change-Id: I40f1b15ffd474d3286356f3151eacd9a4a09add2
The buffers were allocated with B_ANY_KERNEL_ADDRESS and the buffer plus
header block would produce uneven sizes. This lead to some buffers
crossing page boundaries. The call to get_memory_map() is only supplied
with a single entry, which in such a situation may not be enough if the
physical pages are not contiguous. Due to missing result checks this was
not noticed.
Use B_ANY_KERNEL_BLOCK_ADDRESS and align the size of the total buffer
to avoid such page boundary crossing.
Fixes randomly truncated frames in the receive path.
Previously the frame length was set to the allocation size of the buffer
itself, which is constant. Use the length returned on dequeing instead,
which tells how much of the buffer was actually filled.
Fixes overly long frames that lead to various problems along the receive
path.
The size was in fact the count of physical entries that were used. That
number must necessarily be the same as the number given when adding to
the queue, so that number isn't really interesting. Consequently none
of the users of that API made use of it.
Return the used length instead, which is the way virtio signals how much
valid data resides in the dequeued buffer. This is for example important
to know the frame length of incoming packets in virtio_net.
We reuse the incoming request buffer to send our reply. We did however
not trim that buffer to the length we actually filled out, allowing
any extraneous incoming data to remain in that buffer and be sent back.
I forgot that there are special usage texts for the individual
pkgman commands. Make that a bit clearer in the usage text now.
Change-Id: Ia6641b2aa20d03a67d9dedddabf3a1f34d324322
Reviewed-on: https://review.haiku-os.org/702
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
