There are some more in telnetd and agg but I'm not sure if they are
intentional, the code is so ugly there.
Change-Id: I9cc2bf8a919c3b1d6c68f2ded8622730497b0f91
Reviewed-on: https://review.haiku-os.org/c/1598
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
This is more in line with how OpenBSD and FreeBSD do this detection;
and should provide at least some support for USB 3.0+ hubs.
Potentially helps with #15001.
Change-Id: I313400b790b52fbca490c9fc8b721bedb97a64f9
PVS studio new report, warning type V597
Change-Id: Icd85aadf3ffc587806f9a24d224d0a369d4ce0e0
Reviewed-on: https://review.haiku-os.org/c/1594
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The string "(%count% more to download)" is sensitive to
different plural forms in other languages. For example, in
German one could have:
"1 weiterer Download" and
"12 weitere Downloads"
Change-Id: I3ab98cca6ae5066f7558e9ce22c97b6c37ec4a9c
Reviewed-on: https://review.haiku-os.org/c/1593
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This revealed that StopEndpoint commands on QEMU were returning ...
after the semaphore timeout was already hit. Now to figure out
why that is the case...
Put the EventThread as URGENT_PRIORITY and the downstream FinishThread
as URGENT - 1. Hopefully this will serve as a better hint to the
scheduler as to what we want to occur here.
The "event" thread is what is woken up after interrupts, and
the "finish" thread handles the results of the "event" thread,
so prioritize them accordingly. Probably increases responsiveness
of USB input and disk devices visibly on heavily loaded systems.
The USB3 specification changed the meaning of this field, and
it means different things depending on whether a USB 2 or 3
device is attached, so just don't print it.
Fixes listusb saying "Fullspeed" for USB3 devices. The per-device
information already prints what USB version and protocol the
device is operating on, so this was redundant anyway.
It doesn't belong after SUPER, as it's really an extension of USB 2.0
(Linux puts it after HIGHSPEED indeed, as "USB 2.5".) If we eventually
want to support it, we can add it there.
It seems no other OS calls these "Intel" partition types, but instead
MBR partition types. Perhaps we should change this, too?
At any rate, this solves #13260 by blocking installation on GPT
drives altogether.
B_OS_NAME_LENGTH is 32, char* is 8 (on x64), and this structure
has quite a lot of pointers in it so it is not like we really
needed to save those 24 bytes. Hitting malloc() in here is not
so great, especially because we usually have B_DONT_LOCK_KERNEL_SPACE
turned on, so just inline and avoid it.
Change-Id: I5c94955324cfda08972895826b61748c3b69096a
The plugin manager was attempting to buffer the IOs. However, the ffmpeg
plugin already handles this (it reads in 64K chunks, the same size as
the buffer here, so this buffering was effectively useless), and the
media extractor already runs the decoding in a separate thread thanks to
the chunk cache. So, we do not need an extra level of buffering here.
We should leave any extra buffering to the upper layers (BMediaTrack or
Media Extractor), if it's needed, as they would have much more control
on the creation of the data io object.
Change-Id: I65b67919da107c8b910dd08f8cdb8e3745af92c7
Reviewed-on: https://review.haiku-os.org/c/1588
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
The idea was that the Media Extractor could wrap the original source
given by BMediaTrack, but all operations on the data go through
MediaExtractor anyway.
We could probably move ownership of the BDataIO completely into
MediaExtractor instead.
Change-Id: I846b34b543fb983e60f6adf86cb17e835303267b
Reviewed-on: https://review.haiku-os.org/c/1587
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
- Stop using deprecated APIs
- Use BMediaFormat::Clear
- Remove hack for Protracker MOD as we have since got a MIME sniffing rule
- Clarify some comments and fix typos
Change-Id: Id495188cc44dc5af2820fe2a5236a983605b53c4
Reviewed-on: https://review.haiku-os.org/c/1586
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Under normal circumstances (slab allocator) this change is a no-op
because malloc_etc just calls block_alloc unconditionally. Under
the debug or guarded heap, this makes allocations go through that
instead.
I didn't do anything with sparc for a few weeks (you don't want this
machine running when temperatures already are over 30°...), and I wastd
some time finding back some of the useful information, such as commands
to boot and debug, load and execution address of the bootloader program,
etc. So let's keep these in the documentation directory.
Change-Id: I293e0eea3063d410d66f9b2397c2cf0bdbfc6753
Reviewed-on: https://review.haiku-os.org/c/1581
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The sparc openboot implementation can run executables in the a.out
format. We used to generate these using objcopy, but this does not work
anymore as binutils is deprecating a.out format support.
- Import elf2aout from FreeBSD
- Add some missing bits to our elf.h and have a copy of it in the build
headers so it can be used to build elf2aout for the host platform
(tested for Linux)
- Use it to generate the sparc haiku_loader
- Adjust the bootloader linker script to have two "program headers": one
that is not loadable and contains the ELF headers, and the second one
that is loadable and contains the actual code and data. Unlike
objcopy, elf2aout relies only on the program headers to know what to
put in its output file (sections are ignored), so this is required
otherwise we end up with the ELF header nested inside the a.out file,
and everything offset from the expected load address as a result.
Confirmed that this allows to build the loader and run it as far as
before, so I'm back to needing to implement some MMU support now.
FreeBSD commit: 7551d83c353e040b32c6ac205e577dbc5f2c8955
Change-Id: I90b48e578fa7f148aeddd8c5998fdddc5cfa73fa
Reviewed-on: https://review.haiku-os.org/c/1557
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We now record how long it takes to write a block (on average), and then
utilize this information to reduce the timeout write thread's timeout
(to 2 * block_count * average_block_time, so we don't completely
congest the drive.) Remove the "TODO" about the I/O scheduler;
this new logic will be just fine even under an I/O scheduler.
Note that this change goes both ways: while faster writes mean more
writes and quicker, slower writes will increase the timeout before
we do another one also. This then also guards against queueing
another write while one is already in progress, which was
not handled before.
Tested in KVM. Even on a SATA-backed spinning HDD, this reduces
the timeout to around *200ms* on average (!!), so a 10x improvement.
On a ramdisk, it reduces the timeout to *10-30ms* (!!!) on average,
so a 100-200x improvement, so this change will benefit everyone
but SSDs especially.
Since BFS inode and journal writes always go through the block_cache,
this very dramatically improves inode-related write performance.
The "stop and start" stutters when emptying or moving items to Trash
seem totally gone, among a lot of other things.
Change-Id: I41f46a6432ce1f50f896a853abdfe22dde0ba327
Passing a type& to a va-args turns it into a pointer as per
the Itanium ABI; but we shouldn't rely on such trickery.
Explicitly capture a reference to it instead.
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
In cases where scsi_periph checks the size of the buffer supplied to an
ioctl call (functionality added in commit ff4af513e1) this information
needs to be provided by the caller to avoid failure.
Fixes#15094.
Change-Id: I37f2776edbe977e9825ec1837fb763a3b2aa7220
Reviewed-on: https://review.haiku-os.org/c/1584
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Terminal calls this multiple times a second per open tab, so it
was spamming up my malloc logs. I don't see any reason this 60-byte
structure needs to be on the heap; so, leave it on the stack instead.
Change-Id: I3f1ac14fe9bfec39cd0d5668c68f84467450b0c0
Reviewed-on: https://review.haiku-os.org/c/1580
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
