* Set mime type when exporting to file.
* disable netpositive stuff (only css).
* export only the table when not saving to file (clipboard).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23850 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added HTML export, and provision for more formats and clipboard export.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23848 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use our own BBitmapStringField implementation which also requires our
own BColumn implementation. This is just a visual improvement which makes
both the eventual partiton icon and device label indent with the outline
level of the list item
* when setting the Unmount menu item enabled state, check wether the
partition in question is the /boot volume and disallow unmounting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23845 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added it to the image, and configured it to be used.
* Currently, it cannot transfer files over 64 KB for some reason
("Message too long").
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23843 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added sigmask() macro.
* Fixed libutil.h I broke yesterday: it's thought to add functions only if
you've included some other headers before; added the correct header guard
we're using for our sys/param.h.
* Added pidfile.c to the build.
* Fixed warning in realhostname.c, and pidfile.c.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23840 a95241bf-73f2-0310-859d-f6bbb57e9c96
When specified it desigantes that the interrupt handler should not lock the
vector with a spinlock when executing the installed interrupt handlers. This
is necessary to allow the same interrupt vector to be handled in parallel on
different CPUs. And it is required for the CPU halt to work synchronously when
there is more than one AP CPU. Though the acquire_spinlock() should cause IPIs
to be processed, only this fixed the SMP_MSG_FLAG_SYNC problem for me.
Not locking is safe as long as it is guaranteed that no interrupt handler is
registered or removed while the interrupt handler is running. We can guarantee
this for the SMP interrupt handlers we install in arch_smp_init() as they are
never uninstalled. Probably this flag should be made private though.
Restored the SMP_MSG_FLAG_SYNC when entering the kernel debugger.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23838 a95241bf-73f2-0310-859d-f6bbb57e9c96
(must also compare to BSD; I've looked at their sources, but I might have
missed something).
* Added sys/file.h and the flock() system call.
* common_fcntl() could forget to put back the file descriptor on some error
conditions (I guess we should introduce and use a DescriptorGetter class).
* Cleaned up fcntl.h, moved the BSD extensions S_IREAD and S_IWRITE to
sys/stat.h where they belong, and added the missing S_IEXEC to them.
* Added some more comments.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23836 a95241bf-73f2-0310-859d-f6bbb57e9c96
This builds only with GCC 4, mostly because it needs libstdc++ v3
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23834 a95241bf-73f2-0310-859d-f6bbb57e9c96
file position in case an offset was specified.
* Reverted r23828-r23830 in File.cpp: don't fix the symptoms but the cause
of the problem (hey, that has to be in the kernel, right? :))
* Cleanup of File.cpp, removed OpenBeOS namespace.
* Moved user_fd_kernel_ioctl() to the section where it belongs to (that
function should be renamed, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23832 a95241bf-73f2-0310-859d-f6bbb57e9c96
ReadAt() and Read() with regards to the file position. Ie, WriteAt()
is not supposed to modify the data pointer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23830 a95241bf-73f2-0310-859d-f6bbb57e9c96
position before calling _kern_read() and reset it afterwards.
*NOW* this fixes bug #1200 in all cases.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23829 a95241bf-73f2-0310-859d-f6bbb57e9c96
missing attributes).
I hope nothing relies on the previously broken behaviour.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23828 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added {get|set|end}usershell() functions.
* Define MAXLOGNAME, and L_SET, L_INCR, and L_XTND.
* The pidfile stuff in libutil.h is now included, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23827 a95241bf-73f2-0310-859d-f6bbb57e9c96
to fix bug #1731.
* However, it turns out that depot destruction obviously doesn't work
correctly, at least we keep partial or full slabs around when we're
using them (which causes the code to panic).
* Therefore, I've now disabled depots completely, until I find the time
to really work on that code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23825 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added optional tracing for the main operations
* fixed bad pointer arithmetic when reallocating/moving the object's data
* it was impossible to remove the very first space via _RemoveSpaces()
* added a little more variaty to error return codes for some
functions to make them a little more helpful
-> This fixes the bogus space values in DriveSetup (#1737)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23824 a95241bf-73f2-0310-859d-f6bbb57e9c96
HaikuBuildCompatibility.h; this fixes building agp_gart and the intel
extreme driver for BeOS.
* Added sockaddr_storage to HaikuBuildCompatibility.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23823 a95241bf-73f2-0310-859d-f6bbb57e9c96
* While this is not a really good idea for a lock with supposedly little
contention, but it'll fix bug #1731. I haven't tested it yet, but will
do so in a minute :-)
* I will need to rework the slab anyway so that it's possible to use it
as a replacement for our heap, and then I'll switch back to a benaphore
again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23822 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added explicit example for enabling debugging for a subtree.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23818 a95241bf-73f2-0310-859d-f6bbb57e9c96
PrepareModifications() on the parent BDiskDevice first. Hm. I should
probably reorganize things a bit.
* Selecting these empty spaces is still not supported.
* Fixed inserting empty spaces in the DiskView at the correct index.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23812 a95241bf-73f2-0310-859d-f6bbb57e9c96
partitions - I couldn't test it yet, but what is definitely missing
is being able to select these spaces to create new partitions on them
* fixed the bug that if you select a partition on another disk, the
disk view does not switch to the new disk. (I was comparing disk
pointers, but since I deleted the old BDiskDevice instance first, the
new one got assigned the same pointer... at least it appears I am not
leaking memory anywhere... :-))
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23811 a95241bf-73f2-0310-859d-f6bbb57e9c96
destination of the message and it's "what" field are stored. It might be
nice to also get some info about its fields -- maybe as an additional
option.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23810 a95241bf-73f2-0310-859d-f6bbb57e9c96
_kern_ktrace_output() syscall, since it will be stored in a separate
entry anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23807 a95241bf-73f2-0310-859d-f6bbb57e9c96
for reading my commit and noticing! :-)
Using the test application I could have found that bug; that codepath is
currently not used in Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23801 a95241bf-73f2-0310-859d-f6bbb57e9c96
confirmation after sending off the startup IPIs. We simply moved on and setup
the temporary stack address for the next CPU to be started. With this it was
possible that the trampoline code did not manage to load the address before
we overwrote it. So for configurations with more than two CPUs it was possible
that two CPUs were setup to the same kernel stack which could have caused all
sorts of things - most likely a tripple fault and a reboot. On real hardware
this seems very unlikely but it was easily reproducible with QEMU and -smp >2.
We now use the shared trampoline stack to implement a notification mechanism.
The trampoline code will clear the stack location variable once it has loaded
everything it needs from the trampoline stack. On the other side
smp_boot_other_cpus() will wait for this variable to be cleared after it sent
the startup IPIs so that it knows when it can safely move on and overwrite the
area to boot the next CPU.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23800 a95241bf-73f2-0310-859d-f6bbb57e9c96
the GTT is not part of the stolen memory. However, the BIOS popup seems
to be - removing that page solves the flickering overlay when its buffer
contained it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23799 a95241bf-73f2-0310-859d-f6bbb57e9c96
